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

No annotations exist, so the description carries the full burden. It does disclose the returned payload shape (image list with hotspot names and normalized coordinates), which is useful since there is no output schema. However, it says nothing about read-only semantics, permissions, pagination, or behavior when a course has no images.

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 well-formed sentence with the resource front-loaded and no filler. It is appropriately sized for a simple list operation, though it leaves obvious gaps that brevity does not excuse.

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 return content is reasonably covered for a tool with no output schema, but the required input parameter is undocumented in both schema and description, and no annotations supply safety or prerequisite context. An agent can guess 'course_dir' from the name, but the definition stops short of being self-sufficient.

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 single required parameter 'course_dir' has no title annotation or description. The description never mentions the parameter at all, so its meaning (a directory path? a course identifier?) is left entirely to inference.

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 names a specific resource and verb — it returns the course's images along with each image's hotspot name and coordinates. The '(0~1)' note further pins down that coordinates are normalized, so an agent knows exactly what data comes back. It does not explicitly contrast with any sibling, but the asset/hotspot domain is distinct from the audio, lesson, and build tools.

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 statement of when to call this versus alternatives, no prerequisite (e.g. that the course must exist or be initialized), and no exclusion. The agent must infer usage purely from the one-line purpose.

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 full burden. It usefully discloses incremental behavior (skipping unchanged lessons) and an implied runtime/long-run risk for large batches, but never states that existing mp3/timing files are overwritten, how 'force' interacts with the skip logic, or what happens on TTS failure.

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 what is produced, followed by skip behavior and batching advice. No filler; every sentence carries information.

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?

No output schema exists, and the description does compensate by naming the exact output artifacts. However, for a 4-parameter mutation tool with zero annotation and zero schema coverage, the undefined force/voice semantics and overwrite behavior leave meaningful 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 must compensate. It only explains lesson_id (batch one at a time) and hints at course_dir via lesson paths; 'force' and 'voice' are entirely undocumented anywhere, leaving half the parameters opaque.

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+resource: synthesizes lesson audio (audio/lNN.mp3) and per-sentence timing (timing.json) via Supertonic TTS. It is clearly distinguishable from speech_preview as a batch lesson-level operation, though it never names the sibling explicitly.

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 concrete operational guidance: unchanged lessons are skipped, and when there are many lessons, pass lesson_id one at a time and run in batches. It does not say when to prefer speech_preview or lesson_validate instead, so no explicit alternative routing.

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, but for a zero-parameter reference read the burden is low and "읽으세요" (read) communicates that this is a non-mutating retrieval. It does not state whether content is static, versioned, or cached, which would be the remaining useful detail.

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: the first front-loads what the guide contains, the second states when to use it. Nothing is duplicated or wasted, and the ordering matches how an agent should reason about 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?

For a parameterless documentation tool with an output schema, the description covers both the content scope and the invocation timing, which is nearly everything needed. The only omitted context is whether the guide is authoritative/current or how it relates to lesson_validate rules.

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 applies. An output schema exists, so return-value semantics are handled structurally rather than in prose.

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 the resource (a guide) and enumerates its exact contents: lesson JSON format including op, scene options and widgets, motion rules, and TTS sentence authoring. No sibling tool in the list overlaps with this documentation role, so an agent can distinguish it from lesson_save, lesson_validate, or speech_preview without opening anything.

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 an explicit trigger condition (read before authoring a lesson), which is the key routing decision for a reference tool. It does not name exclusion cases or point to alternative tools once the guide has been consumed, which keeps it 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?

With no annotations, the description must carry behavioral disclosure. It does disclose the key trait that the code is actually executed (a real side effect, not a static check) and pins the runtime per language, which an agent needs. It says nothing about sandboxing, timeouts, permissions, or what happens on compile failure versus mismatch, which are significant gaps for arbitrary code execution.

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 tight sentences with no filler, and the core action is front-loaded before the runtime detail. Nothing is wasted, though the brevity comes partly at the cost of the missing content noted elsewhere.

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?

This is a code-execution tool with no annotations, no output schema, and zero parameter documentation. The description should at minimum state what a result looks like (pass/fail, diff, exit code) and what course_dir anchors, since none of that exists in structured fields.

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 neither course_dir nor lesson_id is documented anywhere. The description never references either parameter, so it fully fails to compensate for the coverage gap; only the optional/required split is inferable from the schema itself.

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 names a specific verb+resource: it compiles and executes a code block and compares the console output (out/write) against expected output. This is far more than restating the name 'code_verify'. It does not, however, distinguish itself from siblings like lesson_validate, which also plausibly concerns checking correctness.

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 on when to use this versus lesson_validate or course_build, and no stated prerequisites such as a sandbox environment or a lesson_id requirement. The only contextual hint is the runtime note (mono/dotnet for C#, python for Python), which is language selection, not usage routing.

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 it does disclose one genuinely useful trait: lessons lacking audio advance silently using estimated time. However, it says nothing about whether existing files in out_dir are overwritten, whether the build is idempotent, what permissions or disk usage are involved, or what it reports on completion — significant gaps for a file-writing 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?

Two tight sentences with no filler, and the primary output is front-loaded. Nothing is wasted, though the brevity comes partly at the cost of the missing information noted elsewhere.

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 two-parameter build tool with no annotations and no output schema, the description should cover input sources, output destination defaults, and overwrite behavior. It covers only the output artifact and one fallback behavior, so an agent cannot confidently invoke it with non-default arguments.

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 and does not: neither course_dir (source of lessons) nor out_dir (destination, default null) is explained. The mention of 'dist/index.html' only vaguely hints at the default output location, leaving both parameters semantically opaque.

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 names a concrete verb-and-resource pair (builds a single-file HTML player at dist/index.html plus audio files) and even states the behavioral fallback for audio-less lessons. It is clearly distinct from course_init and lesson_save, though it never explicitly says the course content comes from course_dir, leaving the input-output relationship to inference.

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 statement of when to call this versus siblings such as course_init (scaffolding) or audio_synthesize (audio generation alone), nor any prerequisite like running lesson_validate or course_init first. The agent must guess at the pipeline position of this tool.

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 behavioral burden but only states that a folder is created. It omits what happens if the directory exists, whether it's destructive/reversible, what files are scaffolded, and any permission requirements — significant gaps for a mutation 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?

Two tightly packed sentences with the purpose front-loaded and the parameter value hints following. No wasted words, though the terseness borders on under-specification rather than maximal helpfulness.

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 5-param mutation tool with no annotations and no output schema, the description should explain the required course_dir/title, the effect of the operation, and the relationship to course_build. It provides only the purpose and two value hints, leaving the workflow context 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?

Schema coverage is 0% (no descriptions, no enums), yet the description usefully specifies the allowed values for code_lang (csharp|python) and voice (F1~F5, M1~M5), which the schema lacks as enums. However, title, subtitle, and course_dir remain undocumented, so it only partially compensates.

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 clear verb+resource: '새 코스 폴더를 만듭니다' (creates a new course folder). An agent can understand the action, though it doesn't explicitly differentiate from siblings like course_build or authoring_guide that also relate to course setup.

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?

No indication of when to use this versus course_build, authoring_guide, or lesson_save. Prerequisites like whether the course directory must already exist, or the recommended workflow order, are absent.

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 full behavioral burden. 'Shows' implies a read, but it never states that the operation is non-mutating, what happens if course_dir does not exist, or whether it inspects the filesystem versus an in-memory project.

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 compact sentence that front-loads the outcome and lists the returned fields without waste. It is appropriately sized, though it could have spent one more clause on the required input.

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 description effectively enumerates what the call reports back, which substitutes for the missing output schema. However, with no annotations and an undocumented required parameter, an agent still lacks enough to call it confidently with a valid course_dir.

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 single parameter course_dir is not mentioned in the description at all. The agent gets no guidance on whether it is a path, a course ID, or a slug, so the description fails to compensate for the schema gap.

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 verb ('보여 줍니다' / shows) and enumerates the concrete resource contents: lesson list, scene count, format issue count, audio status. That clearly distinguishes it from mutation siblings like course_build or course_init, though it never names a sibling to route against (e.g. lesson_get).

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 statement of when to call this versus lesson_get, lesson_validate, or assets_list, and no preconditions (e.g. the course must already be initialized). The agent must infer usage entirely from the name and the enumerated outputs.

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 full disclosure burden. 'As-is' (그대로) is a useful note that no transformation occurs, but it says nothing about required permissions, behavior when course_dir or lesson_id does not exist, or error conditions for what is likely a file-backed read.

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 short sentence with the action front-loaded and the usage hint in a trailing parenthetical. Nothing is wasted, though the terse phrasing leaves the tool under-explained rather than over-explained.

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?

With no annotations, no output schema, and 0% parameter coverage, the description should explain the shape of the returned lesson JSON and the meaning of course_dir. It does neither, leaving meaningful gaps for a tool that is the read half of an edit workflow.

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 neither course_dir nor lesson_id is documented anywhere. The description only implies that a single lesson is fetched and adds no detail about whether course_dir is a path or slug, nor what lesson_id indexes into.

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 ('레슨 JSON 하나를 그대로 돌려줍니다' — return one lesson JSON verbatim), which lets an agent distinguish it from lesson_save or lesson_validate. It does not name any sibling tool explicitly, so it stops short of full differentiation.

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 '(고쳐 쓸 때)' signals the intended context — use this before editing a lesson — which implicitly pairs it with lesson_save. However, no alternatives are named, and there is no guidance on when not to use it or on prerequisite ordering with lesson_validate.

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 two valuable traits — the validation gate and that an existing file with the same id is overwritten — but says nothing about what happens on validation failure, whether it returns errors, or what the file path pattern NN resolves to. Overwrite is disclosed, but overall coverage for an unannotated mutation tool is thin.

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 short lines, with the operation and the overwrite caveat front-loaded and the object shape as a compact reference. No wasted prose, though the schema example is bare.

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 two-parameter mutation tool with no annotations, no output schema, and an untyped nested object, the description covers the shape of lesson but omits course_dir semantics and any return/error behavior. Adequate to start, incomplete 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 lesson parameter is a free-form nested object, so the inline key list (id, group, title, sub, ops) adds real value beyond the schema. However, course_dir — a required parameter — is completely unexplained, leaving half the parameters 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 concrete two-step verb sequence (validate then save) on a specific resource, plus the destination path 'lessons/NN.json'. It doesn't name lesson_validate or explain how it differs, so sibling differentiation is only implicit in the validate-then-save phrasing.

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 conditional 'if there are no errors, save' implies when the tool proceeds, but there is no explicit when/when-not guidance and no mention of the sibling lesson_validate as the check-only alternative.

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 full behavioral burden. It usefully discloses the categories of validation performed and the default 'all lessons' scope, but it does not clarify permissions, whether validation is purely read-only, or how results are returned.

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 two compact clauses, front-loads the purpose, and uses a parenthetical to list concrete validation examples without wasted text. Every part contributes useful information.

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 two-parameter validation tool with no output schema and no annotations, the description covers the core purpose and one parameter's default behavior. It remains incomplete because course_dir is unexplained and the result/error behavior is not described.

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 for both parameters. It explains the lesson_id semantics ('비우면 전체' / empty means all) but says nothing about course_dir, leaving one of two parameters 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 uses a specific verb ('검사합니다' / validates) and resource ('레슨 형식' / lesson format), and enumerates concrete checks such as missing code lines, unknown op/widget, and hard-to-read words. It is clear what the tool does, though it does not explicitly contrast itself with siblings like code_verify or course_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?

It gives one useful usage rule: if lesson_id is empty, all lessons are validated. However, it does not say when to use this tool versus related siblings such as code_verify or course_status, so broader usage guidance 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 supplied, so the description carries the full behavioral burden. It implies a persistent mutation ('등록합니다') but never says whether an existing reading is overwritten, whether it requires a valid/initialized course, or what happens on duplicate words.

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 short sentences, front-loaded with the action and followed by a concrete example; nothing is padded. It is efficient, though brevity here comes at the cost of the missing details noted elsewhere.

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?

A mutation tool with no annotations, no output schema, and 0% schema coverage needs the description to cover prerequisites and side effects, and it does neither. Only word/reading get any explanation, leaving course_dir and persistence behavior undocumented.

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% with three required parameters. The example clarifies the roles of word and reading, but course_dir — the most consequential parameter — gets no explanation of its format, whether it must exist, or how it is identified.

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 resource: it registers ('등록합니다') the Korean reading of an English word into a course. The example (word="Dictionary", reading="딕셔너리") makes the operation concrete and clearly separates it from authoring siblings like lesson_save or course_build.

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?

No guidance on when to use this versus siblings, and no prerequisites stated — notably it never says a course must already exist or how course_dir is chosen. The example illustrates input shape but not the conditions that select this tool.

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?

Since no annotations are provided, the description bears a high burden, which it meets by disclosing significant behavioral details. It explains the exact file naming convention, the generation of spatial data, provides a list of helper functions (e.g., mat, spot, camera), and specifies dependency environment configurations.

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?

Despite being technically dense and covering three topics (generation, usage, environment), the information is logically grouped and readable. It is efficient in its comprehensive delivery of complex technical instructions.

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 complex 3D rendering tool, the description is very complete. It provides the context for why the hot-spot coordinates are generated (lesson integration), the required scripting format, and the necessary environment setup to run the tool.

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 schema description coverage is 0%, meaning the description must cover all parameter meaning. The text only elaborates on the purpose of 'name' and 'script' within the context of hot-spot generation, providing virtually no semantic guidance for 'width', 'height', or 'samples'.

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 is highly specific, stating that the tool renders a 3D scene using Blender to generate both an image (assets/<name>.png) and hot-spot coordinates. It clarifies the input requirement of using a bpy Python 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?

While it does not explicitly list alternatives, it provides clear workflow instructions, specifically requiring a bpy Python script for scene creation. It also instructs users on prerequisite environment setup, including setting the FLS_BLENDER variable.

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 conveys meaningful behavioral content (this returns the actual read-aloud text per scene plus flagged fragments, i.e. a read/preview operation), but it never explicitly states that it is side-effect-free or describes formatting of the returned text. Reasonable but incomplete for a zero-annotation 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?

A single focused sentence with no filler, and the core purpose (showing read-aloud text) is front-loaded. Efficient, though slightly short given what it must convey.

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?

No annotations, no output schema, and two completely undocumented required parameters. The description explains the output concept but leaves the agent without the information needed to supply course_dir and lesson_id correctly or to know the operation's safety profile.

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 neither course_dir nor lesson_id is mentioned in the description. The scene-level framing gives faint context that a lesson is being inspected, but no parameter's meaning, format, or role is clarified.

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 resource: it shows, scene by scene, the sentences TTS will actually read and flags hard-to-read fragments like English words. This is clearly distinct from action-oriented siblings such as audio_synthesize or pronunciation_add, though it never names or contrasts those siblings explicitly.

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?

No when-to-use context is given, no prerequisites, and no guidance on when to prefer this over audio_synthesize or pronunciation_add. The agent must infer the preview-vs-synthesize distinction entirely on its own.

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