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

With no annotations, the description carries the full burden and does well: it discloses that pauses of 1.5s are inserted between chapters, that output is loudness-normalized to -16 LUFS, and that missing segments cause failure unless allow_missing=true. It omits whether existing output files are overwritten or what happens on partial failure, which keeps it below 5.

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?

Two dense sentences with no filler; the output targets and the allow_missing flag are front-loaded. The arrow notation and parentheticals pack a lot of meaning efficiently.

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?

An output schema exists, so return values need not be described, and the description covers outputs, normalization, pause behavior and the draft mode. For a file-writing tool with no annotations, the main remaining gap is overwrite/side-effect disclosure.

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 coverage is 0%, so the description must compensate for 4 undocumented parameters. It fully explains allow_missing and partially implies loudnorm (normalization to -16 LUFS), but leaves run and format unexplained, and oddly describes pause_after_ms which is not in the schema. Coverage is partial.

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 (ghép/assemble) plus resource (audio segments in script order) and names the exact output artifacts out/story.wav and out/story.mp3. It is clearly distinguishable from siblings like tts_render, though it never explicitly contrasts itself with them.

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?

It gives one concrete usage condition – allow_missing=true for building a draft when some segments aren't read yet – which implies when the tool is appropriate. However, there is no guidance on prerequisites (e.g. whether all segments must be rendered first) or on when to prefer assemble_audio over qa_audio/tts_render in a workflow.

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

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

With no annotations, the description carries the burden and does so well: it discloses that the tool writes two artifacts (check.json, script.md) and enumerates the exact blocking error categories and warning categories, including the conditional voice_unknown check that depends on the TTS server running. It omits permission/auth requirements and whether outputs are overwritten, keeping it below 5.

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?

Two sentences, dense but front-loaded: the primary action and outputs come first, followed by the error/warning taxonomy. No filler sentences, though the error list is compressed enough to require careful parsing.

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?

An output schema exists, so return values need not be described, and the description covers the validation semantics and side effects thoroughly. The notable remaining gap is the unspecified 'run' parameter, which an agent needs in order to call the tool at all.

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 coverage is 0%, so the description must compensate. It does explain max_overlap ('% cụm 6 từ trùng bản gốc > max_overlap') and implicitly touches max_segment_chars via the segment_too_long warning, but the required 'run' parameter is never explained, leaving the most important argument undocumented.

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?

Names a specific verb+resource chain: validates story/cast.json + script/script.json, emits script/check.json, and rebuilds script/script.md for review. It also indirectly distinguishes itself from the sibling tts_render by stating that errors here block that tool, though it does not explicitly compare against other siblings.

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?

Usage is implied through the pipeline: run this before tts_render, since errors 'chặn tts_render'. There is no explicit when-to-use/when-not statement or named alternative, so context must be inferred from the workflow description.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the scope of the checks (the specific components probed), which is useful, but says nothing about whether it is strictly read-only, whether failures abort or are merely reported, or how long it takes — leaving safety and failure semantics to inference.

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 clause lists exactly the checks performed with zero filler. Every token earns its place, and the enumeration format matches the diagnostic nature of the tool.

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?

An output schema exists, so return values do not need explaining, and the description fully enumerates what is probed, which is what an agent needs to decide to call it. The only gap is the missing guidance on when in a workflow to invoke it.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly reflects that no input is required.

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 verb 'Kiểm' (check) plus an explicit enumeration of what is inspected — ffmpeg, yt-dlp, the STT engine, the VieNeu server, and the run directory — makes the tool's function unambiguous. No sibling in the list (transcribe, tts_render, list_runs, etc.) overlaps with a preflight diagnostics tool, so it is distinguishable by resource and intent.

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?

The description never states when to run this check, whether it is a prerequisite before transcribe/tts_render, or what to do if a check fails. The 'doctor' naming convention implies a preflight role, but that is convention, not stated guidance, and no alternatives or exclusions are mentioned.

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

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

With no annotations, the description carries the full burden. It does disclose the meaningful side effects: it creates a run directory, downloads audio, and pulls metadata plus Vietnamese subtitles when available, and it returns run_dir. It says nothing about network/auth requirements, what happens on an invalid YouTube link or unsupported file, or whether re-running overwrites an existing run folder.

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?

Three sentences, front-loaded with the core action and the input variants, then the return value, then the optional flag's tradeoff. Dense but every sentence adds information; only the parenthetical extension list is slightly padded.

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?

An output schema exists, so run_dir need not be explained in depth, and the workflow position ('dùng cho các tool sau') is covered. Still, for a network-touching tool that writes a new run folder, the unexplained 'title' parameter and the absence of any failure or overwrite behavior leave real gaps.

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%, so the description has to compensate. It explains 'source' well (YouTube URL vs. local .mp3/.m4a/.wav and .vtt/.srt/.txt/.md paths) and gives the semantics of with_audio=false. The third parameter, 'title', is never mentioned, leaving one of three parameters undocumented in both schema and description.

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 and artifact: 'Tạo thư mục run mới' (create a new run folder), and enumerates precisely what it ingests – a YouTube link or a local audio/subtitle/transcript file. An agent immediately knows this is the entry point that materializes a run workspace, which is distinct from siblings like list_runs, transcribe, or run_status.

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?

Gives a clear conditional: with_audio=false when you only need metadata plus subtitles and are confident the subtitles are good enough. It also tells the agent this must happen before 'các tool sau' (subsequent tools). It does not name an explicit alternative tool or state exclusions, 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.

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

No annotations are provided, so the description carries the burden; it does disclose a genuine behavioral detail the schema cannot — the storage location and its $AUDIO_STORY_RUNS_DIR override with default ./audio-story-runs. It says nothing about ordering (newest first?), whether the scan is recursive, or behavior when the directory is missing, which matters for a filesystem-backed tool.

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?

One front-loaded sentence with no filler; the verb+resource lead and the scoping detail trails it. Nothing is wasted, though nothing is added beyond that single clause either.

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?

Complexity is low, there are no required parameters, and an output schema exists so return shape needn't be described. The remaining gaps — limit semantics, ordering, and empty/missing-directory behavior — leave an agent with an incomplete picture of how to call it correctly.

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?

The single 'limit' parameter has 0% schema description coverage and is not mentioned in the description at all, so its meaning (count of runs? default 20 but max?) is undocumented everywhere. The description also doesn't clarify that it limits the 'most recent' set.

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 ('Liệt kê') and resource ('các run'), plus the scope (root directory), so an agent can tell it lists runs rather than reporting on one. It never names the closest sibling run_status, however, so differentiation is inferred rather than stated.

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 explicit when-to-use or when-not-to-use guidance and no alternative is named. An agent must infer from 'most recent runs' that this is the discovery/listing entry point before drilling into run_status, rather than being told so.

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

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

No annotations are provided, so the description carries the burden alone. It does disclose that this talks to a live server and reports server status, which implies a network dependency and a possible unavailable-server condition, but it never states failure behavior, cost, or whether results are cached. Return values are covered by the output schema, so that gap is acceptable.

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 stating the resource first, then the downstream use of the result, then the secondary server-status capability. No filler, no repetition of the tool name.

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 zero-argument read tool with an output schema, the description supplies the one thing the schema can't: where the returned voice ids are consumed. The only missing piece is guidance on server-unavailable behavior or the doctor overlap, which is a minor gap at this complexity level.

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?

The tool takes zero parameters, which is the documented baseline of 4. The description adds no parameter confusion and correctly frames the output id as an input to another tool's field.

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?

Specific verb+resource ('Danh sách giọng' / list voices) scoped to the VieNeu-TTS server, plus the extra detail that the returned id is what goes in `narrator.voice` in cast.json. That clearly separates it from list_runs or transcribe. It stops short of explicitly distinguishing itself from doctor, which also surfaces server status.

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?

The parenthetical about `narrator.voice` in cast.json implies when to call it (when configuring a cast), but there is no explicit when/when-not statement or named alternative. The 'tình trạng server' (server status) clause overlaps with the sibling `doctor`, and the description does not say which to prefer.

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

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

No annotations, so the description carries the full burden, and it discloses non-obvious behaviors: which STT engines are used (openai | whisper), that a report file is written to qa/report.json, and that results are filtered by max_cer. It omits cost/latency, overwrite/idempotency behavior, and permissions, but the core side effects are surfaced.

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?

Two compact sentences with zero filler; the primary action and the file output are front-loaded. Sizing is appropriate for a tool of this complexity.

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?

An output schema exists, so return values needn't be described. But with five parameters at 0% schema coverage and three of them unexplained, the definition does not supply enough to call the tool correctly (e.g., what 'run' identifies, what 'limit' caps).

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 coverage is 0%, so the description must compensate, but it only hints at max_cer (the threshold) and engine (openai|whisper — and even omits the schema default 'auto'). The required 'run' parameter, 'limit', and 'segment_ids' receive no semantic explanation anywhere, leaving most inputs undocumented.

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 chain (listen back via STT, compute CER vs. TTS input, write qa/report.json, return segments over threshold) that is clearly distinct from siblings like transcribe or tts_render. It does not explicitly name the sibling it is not, but the QA-scoring angle is unambiguous.

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?

The second sentence implies the downstream workflow (fix pronunciation in pronunciation.json, then re-read), giving useful context for when this tool fits. However, it never states prerequisites, exclusions, or why an agent would choose this over transcribe (also STT-based) — usage is only implied.

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

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

No annotations are provided, so the description must carry the behavioral burden. 'Status' strongly implies a read-only inspection tool, and it discloses the categories of information returned, but it does not explicitly state side-effect behavior, permissions, or whether it triggers any processing.

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?

The description is a single front-loaded phrase with no filler, and it immediately names the resource and the informative contents. It is slightly under-specified but not padded or disorganized.

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?

The tool is simple (one parameter) and has an output schema, so return-value explanation is not required. However, the description leaves gaps around the run identifier semantics and when to choose this over list_runs or doctor, making it adequate but incomplete.

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?

There is one required parameter, 'run', with 0% schema description coverage. The description only says 'một run' and adds no identifier format, source, or lookup guidance, so it fails to compensate for the missing schema documentation.

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 resource and verb-like purpose: it reports the status of a run and enumerates what the status contains (source, existing files, step history, next recommended step). This is clear enough to distinguish it from most siblings, though it does not explicitly contrast with list_runs or doctor.

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?

The phrase 'Trạng thái một run' implies this is used when checking a run's current state, but there is no explicit when-to-use guidance, no exclusion of alternatives, and no mention of siblings such as list_runs or doctor. Usage is therefore only implied.

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

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

There are no annotations, so the description carries the full burden. It discloses the output artifacts, that the openai engine requires an API key, that whisper runs locally, and that the result may be long. However, it says nothing about cost, latency, or failure behavior; for example, what happens if YouTube captions do not exist, or how the 'auto' engine chooses. Those gaps matter for a tool that can make network or GPU calls.

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?

The description is compact and front-loaded: the main action and outputs come first, then a scannable pipe-separated engine list, then the next-step hint. Every sentence earns its place, and nothing obvious is missing. The only cost is that the engine list is dense and relies on parenthetical shorthand.

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?

An output schema exists, so the description need not explain return values, yet it usefully names the produced files anyway. What is missing is a description of what a 'run' is, whether existing transcripts are overwritten on re-run, and how the 'auto' engine selects among the others. Those are important for a tool with three parameters, one required, and no annotation coverage.

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%, so the description must compensate. It does well on engine, giving each option meaning, even though the schema has no enum. But run is not explained and language, including its 'vi' default, is never mentioned. So one parameter is well covered and two are not.

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 gives a specific action and object ("Chuyển audio của run thành chữ") and names the two output files (transcript/transcript.txt with timestamps, transcript.json). That is enough for an agent to understand its role versus the synthesis tools like tts_render or qa_audio. It never explicitly contrasts itself with those siblings, though, so 4 rather than 5.

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?

The description lists every engine value with the condition that selects it (captions = YouTube subtitles, text = existing .txt, openai = needs OPENAI_API_KEY, whisper = local faster-whisper), which is real selection guidance. It also adds a follow-up step, telling the agent to read the resulting transcript.txt with the file-reading tool in chunks. It does not state when not to use the tool, such as when a transcript already exists.

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

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

With no annotations, the description carries the full burden and does well: it discloses the output artifact (WAV), the side effect of writing to disk, the default fallback location ./audio-story-runs/_preview/, and that pronunciation.json from a run is applied when available. It omits auth/permission requirements and whether an existing preview file is overwritten, so it is not fully complete.

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?

Three short sentences, front-loaded with the core action and output format, followed by purpose and the no-run fallback. No filler; it would earn a 5 only if it covered the undocumented parameters instead of stopping short.

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?

An output schema exists, so return values need no explanation, and the file-write behavior is disclosed. However, for a 4-parameter tool with zero schema description coverage, leaving 'name' and the required 'text'/'voice' semantics unexplained is a real gap 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%, so the description must explain all four parameters, but it only covers 'run' (used to pick up pronunciation.json, and its absence redirects output to _preview/). 'text', 'voice' and especially 'name' (default 'preview') are left undocumented, and an agent cannot infer what 'name' controls — presumably a filename or label.

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 (đọc thử / preview-read), resource (one sentence with one voice) and concrete artifact (WAV file), which clearly separates it from the full-render sibling tts_render. It does not name tts_render or list_voices directly, so the differentiation is implied rather than explicit.

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?

'Dùng để chọn giọng / thử cách đọc tên trước khi đọc cả truyện' gives a clear selection context (choosing a voice / testing name pronunciation before rendering the whole story). It does not explicitly exclude anything or name the alternative tool, but the intended workflow position is clear.

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

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

With no annotations, the description carries the full burden and does well: it discloses the output path pattern, idempotent skip behavior, the mandatory check_script gate, and GPU-dependent concurrency. It omits what force does and any permission/rate considerations, so not 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Tight, front-loaded, and every clause carries operational meaning (output location, prerequisite, resume semantics, param hints). The telegraphic style borders on terse but wastes nothing.

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?

An output schema exists so return values need not be explained, and the description covers prerequisites, idempotency, and output paths. The main gap is the undefined 'force' flag and the required 'run' parameter for a 5-param tool with zero schema descriptions.

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 coverage is 0%, so the description must compensate; it explains limit, segment_ids, and workers well. But it says nothing about 'run' (the required parameter) or 'force', leaving two of five parameters, including the only required one and a mutation-style flag, entirely undocumented.

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 (đọc kịch bản / render TTS) and concrete resource (script → audio/seg_XXXXX.wav), plus the voice model (cast.narrator.voice). This clearly separates it from siblings like tts_preview, assemble_audio, and check_script.

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?

Gives explicit preconditions ('Chỉ chạy khi check_script mới nhất không còn lỗi') and the resume pattern (already-rendered segments are skipped, call again to continue). It also routes parameter choice (limit for trial runs, segment_ids to re-read specific segments, workers>1 only with GPU) but never explicitly contrasts with tts_preview.

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