VIDIA

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds two genuinely useful traits not in annotations: the call is free (no point consumption) and it returns balance, coupons, and plan data, which partially compensates for the absent output schema.

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 with zero waste; the resource scope is front-loaded and the free-call note follows immediately.

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 parameters, no output schema, and annotations covering the safety profile, the description is nearly sufficient, enumerating the returned data categories. It omits only the implicit authentication requirement for an account-scoped call.

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 and the schema is empty, so the baseline of 4 applies. There is nothing parameter-related the description could usefully add.

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 (확인합니다/check) and concrete resources (point balance, coupons, plan). It is clearly distinct in domain from every sibling (runs, packages, assets, downloads, quotes), though it does not explicitly name an alternative to differentiate itself.

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 '무료입니다' note implies it can be called without cost concern, which weakly signals when to use it, but there is no explicit when/when-not guidance or reference to sibling tools. Usage is largely inferable from the account-scoped name rather than stated.

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?

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is partly covered. The description still adds genuinely new behavioral facts: the action is irreversible (되돌릴 수 없으니), it requires a user confirmation step before invocation, and it demands a specific permission key. It does not describe what artifacts are lost in the normal path, though the schema's 'confirmed' parameter covers the refund case.

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 action, then the irreversibility warning and confirmation instruction, then the permission requirement. No sentence is redundant.

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 destructive, two-parameter tool with no output schema, the description supplies the operation scope, the irreversibility warning, the confirmation workflow, and the authorization requirement. The only gap is that it never contrasts the normal cancel path with the refund path, which is left entirely to the schema.

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%: run_id ('제작 번호') and confirmed (the full-refund path where created files are deleted) are both documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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 and resource (제작을 취소합니다) and narrows the scope to '진행 중이거나 대기 중인' runs, which cleanly separates it from the sibling vidia_start_run and from read-only siblings like vidia_get_run. An agent can identify the operation and its applicable state without opening any schema.

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 states the condition for use (run is in-progress or pending) and adds two prerequisites: obtain user confirmation first, and hold the '제작 시작 허용' permission key. It does not name an alternative for runs that are already finished, so it falls short of explicit when-not guidance.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds two facts annotations cannot express: the download links expire after 1 hour and the call is free of charge. It does not say what happens if the run is not yet complete, which is the main remaining behavioral gap.

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, with the payload contents front-loaded before the cost note. No filler, though the enumerated list of deliverables could be trimmed if it duplicated an output description (there is none, so it earns its place).

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 output schema, the description carries the return-value burden well by naming the deliverables and the posting title/description. The 1-hour link lifetime is also disclosed. What's missing is failure behavior for unfinished/invalid runs, which an agent would want.

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 100% and the single parameter run_id is documented in-schema as '제작 번호'. The description adds no extra meaning to run_id (format, range, where to obtain it), so the baseline 3 applies.

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 ('완성된 제작의 결과물...을 받습니다') and enumerates exactly what comes back (완성 영상·썸네일·자막, 다운로드 링크, 게시용 제목·설명). It is clearly distinct from vidia_get_run or vidia_start_run in intent, though it never names a sibling to sharpen the boundary.

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?

'완성된 제작의' implies the run must already be finished, which is useful implied guidance. However, it gives no explicit when-to-use/when-not or a named alternative for getting metadata about in-progress runs (e.g. vidia_get_run).

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds cost behavior ('무료입니다') that no annotation conveys, which is genuinely useful for deciding whether to call it, though it does not disclose pagination or error behavior.

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, front-loaded sentences with no filler: purpose first, workflow use second, cost last. Efficient and easy to scan.

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 output schema, the description must convey the return shape, and it does so adequately (description and input keys). Combined with annotations covering safety and the cost note, an agent has enough to invoke it correctly, though the input-key structure itself is not detailed.

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 100% and the single slug parameter is fully documented in the schema, including its origin. The description adds no syntax or format detail beyond that, so the baseline of 3 applies.

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 scope (one package's description and input fields), and singles out the singular retrieval in contrast to the plural sibling vidia_list_packages, which it cites as the source of the slug. Clear, though it does not explicitly state what distinguishes it from the list tool in prose.

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 sentence '견적·제작의 input 은 이 칸의 key 로 채웁니다' implies the downstream workflow (fill vidia_quote / vidia_start_run inputs using these keys), so usage context is inferred. However, no explicit when-to-use or when-not guidance or named alternative is given.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world profile, so the safety story is covered. The description adds genuinely new behavior beyond that: it is cost-free and it carries a polling/rate-limit expectation of at least 30 seconds between calls. It does not describe pagination or error behavior, but for a read-only poll endpoint this is strong added context.

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?

Four short sentences that each do distinct work: purpose and return fields first, then the completion handoff, then cost, then the polling constraint. No filler and the core action is front-loaded.

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 output schema, the description compensates by naming exactly what comes back (status, stage, ETA) and enumerating the status vocabulary. Combined with the 30-second polling rule, cost note, and get_downloads follow-up, an agent has everything needed to call and interpret this read-only endpoint.

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% with a single documented run_id ('제작(프로젝트) 번호'), so the schema already carries the parameter meaning. The description only restates '한 건' conceptually and adds no format, source, or lookup guidance for run_id beyond what the schema provides, making the baseline 3 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?

States a specific verb and resource ('제작 한 건의 상태... 봅니다') with explicit scope limited to a single run, plus the exact returned fields (status, progress stage, ETA) and the enumerated status values. The '한 건' scoping lets an agent separate it from the list-oriented sibling vidia_list_runs without opening a schema.

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 operating instructions ('30초 이상 간격으로 확인하세요'), notes the tool is free, and routes the agent to the correct next step once the run finishes ('완성되면 vidia_get_downloads 로 받습니다'). Both the when and the follow-up alternative are named rather than left to inference.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so credit goes to what is added: the note that listing is free (no quota/cost concern) and that this tool returns ids rather than files. It stops short of describing ordering or pagination behavior of the result.

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 purpose, then the downstream use, then the alternative for uploads. Every sentence carries distinct information with no restatement of the title or 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?

There is no output schema, and the description does state that ids are returned and how they are consumed downstream, which covers the main gap. Minor omissions remain (result ordering, whether names/metadata accompany the ids, behavior when limit is hit), but the essentials for correct invocation are present.

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% and all three parameters (q, kind, limit) are documented in the schema itself with an enum and a max of 200. The description adds no filtering syntax or behavior beyond what the schema already carries, so the baseline 3 applies.

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 verb and resource ('view ids of my library files: image/video/audio') and immediately says what those ids are for — feeding package inputs whose type is 'asset'. No sibling tool lists assets, so there is no realistic confusion with vidia_list_packages or vidia_list_runs.

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?

Explicitly frames the trigger (populate asset-type package input fields, array when multiple) and routes the agent away from this tool for creation ('uploads happen via the web library or REST/SDK POST /api/v1/assets'). Both the when and the when-not are stated, which is exactly what an agent needs to avoid calling the wrong 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?

Annotations already cover readOnlyHint, idempotentHint, destructiveHint=false and the closed-world scope, so the safety profile is fully handled. The description adds useful context beyond annotations by disclosing returned fields (estimate points and working time) and that the call is free, but says nothing about pagination despite limit/offset params.

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 purpose, followed by return-value and cost facts. No padding or redundancy.

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 an optional-parameter list tool with 100% schema coverage and full annotations, the description covers purpose, returned data and cost adequately. Only pagination behavior is left unmentioned, a minor gap with no output schema to reference.

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% with enums and bounds documented inline, so the schema carries the parameter semantics. The description adds no filtering or format detail beyond what the schema already provides, making the baseline 3 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 states a specific verb (찾습니다) and resource (발행된 패키지 / video production templates), and scopes it to published, video-capable packages. This is clear enough to distinguish a listing call from vidia_get_package, though the sibling relationship is not named 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?

It conveys the purpose (finding packages to make videos) which implies when to use it, but gives no explicit when-not guidance or mention of the sibling vidia_get_package for fetching a single package. Usage is inferred rather than stated.

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?

Annotations already carry the full safety profile (readOnly, idempotent, non-destructive, not open-world). The description adds two traits beyond them: results are returned in recency order, and the call is free. It says nothing about pagination behavior or what a run record contains.

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, purpose front-loaded, zero padding. It is efficient, though terse to the point of omitting useful scoping context.

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 simple read-only list tool with no output schema and fully documented params needs little prose. Still, the description never clarifies the run/package/asset distinction among siblings or how the optional filters combine, leaving a real selection gap.

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% with three self-documented optional params (limit, state filter, offset), so the schema does the heavy lifting. The description adds no parameter syntax or semantics beyond it, which is the expected baseline.

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 (list my creations/projects) and adds default ordering (most recent first). It does not differentiate itself from sibling list tools such as vidia_list_packages or vidia_list_assets, and the name/description mismatch (runs vs 'projects') leaves a small ambiguity.

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's free) hints at a cost consideration but is not real guidance. There is no statement of when to use this versus vidia_list_packages, vidia_list_assets, or vidia_get_run, and no prerequisites or exclusions.

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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description discloses three operationally important facts an agent cannot infer: no points are deducted, the quote expires after 10 minutes, and the returned id is the sole key that can start production. This is exactly the kind of lifecycle/cost context annotations cannot carry.

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 returned, then cost, then validity/prerequisite. Every sentence carries distinct, non-redundant information with no filler.

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 output schema, the description usefully enumerates what the quote contains (budget points, estimated cost, scene plan) and adds the expiry and prerequisite that govern the next step. Combined with a 100%-documented 7-parameter schema, an agent has everything needed to call it and use the result.

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% (package, input, mode, title, loop_policy, loop_retries, problem_policy all documented with enums), so the schema does the heavy lifting and baseline 3 applies. The description only refers generically to '입력값' and adds no extra meaning about parameter values or how 'input' keys map to vidia_get_package.

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 action and artifact — it returns a production quote (minimum/recommended budget points, estimated cost, scene plan) for the supplied input. It also implicitly separates itself from the sibling vidia_start_run by stating that production can only be launched from this quote's id, so the agent can place it in the workflow without opening other schemas.

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 clearly establishes the context of use: call this to obtain a quote before production, because starting a run requires the quote id. It does not explicitly name vidia_start_run as the alternative/next step or state any exclusion (e.g., what to do if a quote already exists), so it stops short of full when/when-not guidance.

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?

Annotations only declare this is a non-read-only, non-destructive write. The description adds three non-obvious behavioral facts the agent cannot get elsewhere: points equal to budget are reserved up front and refunded if unused, an authorization key is required, and the package/input/settings must match the quote. This is materially richer than the annotation set.

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?

Four compact sentences that front-load the consent precondition before the billing and permission details. No filler, though the ordering could surface the permission requirement slightly earlier.

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?

Covers preconditions, billing behavior, and authorization for a 13-parameter write tool with a nested input object and no output schema. It never indicates what a successful call yields (e.g. a run id), which is the main remaining gap given the absence of an output schema.

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% and all 13 parameters (including the enum policies and idempotency_key) are documented in the schema, so the baseline is 3. The description reinforces budget semantics (reservation and refund) and the quote-consistency requirement for input/package, but adds little beyond what the schema already states.

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 verb+resource ('제작을 시작합니다') and makes the quote→start relationship explicit ('견적 때와 같은 package·input·설정을 보내야 합니다'), which cleanly separates it from the sibling vidia_quote. It stops short of naming vidia_quote outright, so the routing is implied 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?

Gives a hard precondition and implicit exclusion: call only after the quote has been shown and the user has consented ('보여 주고 동의를 받은 뒤에만 부르세요'). It also requires the '제작 시작 허용' permission key. It does not name an alternative tool for the estimate step, so the when-not-to-call guidance is strong but not complete.

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