VOD 받아쓰기 진행 상황

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds real value beyond them: it says it reports the most recent job only, lists stage/progress/result-file as the payload shape, and warns that course/title text is LMS data rather than instructions — a genuine prompt-injection caveat.

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, front-loaded with the core purpose and with the security caveat kept short and separate. No filler, though the injection note would read better tied explicitly to the result-file field it protects.

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 an output schema present and no inputs, the description need only justify the call: it does so by naming the reported fields and the recency scope. The one remaining gap is not clarifying whether it errors or returns empty when no transcription has run.

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 the baseline is 4; there is nothing to disambiguate. The description correctly implies a no-argument call by referring only to the implicit last job.

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 ('마지막 받아쓰기 작업의 상태를 보여준다') and adds the concrete fields reported (단계·진행률·결과 파일). It scopes to the LAST job, which distinguishes it from generic status checks, though it never contrasts with the adjacent asr_status or transcribe_vod 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?

The phrase '마지막 받아쓰기 작업' implies you call this after starting a transcription, but there is no explicit when-to-use statement, no note that it takes no arguments, and no routing away from asr_status. Usage is inferable rather than stated.

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