tts_jobs_statusGet the public status and result availability of a TTS job. TTS 작업의 waiting, processing, completed, cancelled, failed 상태와 MP3·ASS 자막 준비 여부를 조회합니다. [무료]
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | 작업 접수에서 받은 32자리 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description adds useful behavioral detail beyond that: the operation is public, free, reports status rather than returning binary files, and checks specific artifact readiness. No contradiction exists between the description and annotations.
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 short and front-loaded with the primary action, and it efficiently lists the statuses and artifact checks. The English/Korean duplication is slightly redundant but keeps the tool accessible to both audiences without bloat.
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?
Given a single simple parameter, read-only annotations, and no output schema, the description covers the essential operational facts: what statuses may be observed, which outputs are checked, and the free/public nature. The exact response shape is not described, but for a lightweight status-check tool this is a minor omission.
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 100% for the only parameter, job_id, including its 32-hex-character format and origin. The description adds no extra parameter-level meaning, but with full schema coverage the baseline of 3 is appropriate.
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 ('Get'), names the exact resource ('status and result availability of a TTS job'), and enumerates the states checked (waiting, processing, completed, cancelled, failed) plus asset readiness (MP3/ASS). This clearly distinguishes it from creation, cancellation, and actual result-fetching siblings, even without naming them 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?
The description implies it is meant for polling a TTS job and checking whether outputs are ready, but it does not explicitly say when to use it versus tts_jobs_result or tts_jobs_subtitles. There is no exclusionary guidance such as 'use tts_jobs_result to download the actual files.' The usage context is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose, including the watermark pair: draw_watermark_image is visible text while set_watermark embeds an invisible code. The TTS job lifecycle tools are also cleanly separated by action and output type.
The set mixes conventions: conversion tools use input_to_output, watermark tools use verb_noun, TTS jobs use a tts_jobs_ prefix, and stt is a bare acronym. The names are readable but do not follow one predictable pattern.
At 19 tools, the server sits in the borderline 16-25 range and spans document conversion, image processing, watermarking, audio/video, and async TTS. Most tools earn their place, but the overall surface feels somewhat heavy for a single conversion-focused server.
The server covers its core domains well: document conversions, watermarking with both visible and invisible methods, PDF operations, and a full async TTS workflow. Minor gaps exist, such as missing image-to-PDF or Excel-to-JSON inverse conversions, but agents can generally complete workflows without dead ends.