Skip to main content
Glama
com.woodstitch/tts-human-eval

com.woodstitch/tts-human-eval

Official

woodstitch_export

Read-only

Exports scored human listening judgments from a TTS evaluation as JSON or CSV rows, with optional save_to path for large studies. Retrieve per-judgment rater, clip, speaker, and confidence data.

Instructions

Every judgement as a row (pseudonymous rater, pair/clip id, source, speaker, passage, answer, confidence, time spent). format 'json' returns the rows; 'csv' returns CSV text. Pass save_to (a local path) to write the export to disk instead of returning it, which is better for large studies.

Input Schema

NameRequiredDescriptionDefault
formatNojson
eval_idYes
save_toNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.5

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds real value by explaining the format switch and that save_to writes a file to a local path instead of returning data. It omits how rows are ordered, whether the export is complete or truncated, and what happens if eval_id is unknown.

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?

Three tight sentences, front-loaded with the payload shape, then format semantics, then the disk-write option. The opening fragment 'Every judgement as a row' is slightly clipped but dense with useful detail; nothing is redundant.

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?

With no output schema, the description correctly spends its words enumerating the returned columns and both return modes, which is what an agent needs to interpret the result. The remaining gap is the required eval_id and any indication of export size or failure behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the whole burden. It does define format's two values and save_to's behavior well, but eval_id, the only required parameter, is never explained beyond its 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 the resource precisely: one row per judgement, with the exact column list (rater, pair/clip id, source, speaker, passage, answer, confidence, time spent). That is far more specific than the bare tool name. It does not distinguish itself from the sibling woodstitch_get_results, which an agent would plausibly consider for the same goal.

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 conditional: pass save_to for large studies rather than returning the payload. However, it never says when to use this export versus woodstitch_get_results or woodstitch_list_evals, and it states no prerequisites for a valid eval_id.

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