APICK AI

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

The description adds substantial behavioral context beyond the annotations: immediate point deduction (장수×25포인트 선차감), instant refund for failed images, no cancellation after submission, and per-image pricing. It also confirms the async nature of the operation. Nothing contradicts the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) — the cost and no-cancellation policy are exactly the kind of disclosure that annotations don't capture.

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 with zero waste: the first states the core function and scope, the second covers cost/refund/cancellation policy, and the third states pricing. Information is front-loaded with the primary purpose first, and every sentence 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?

For a 9-parameter, no-output-schema submission tool, the description covers the essential operational aspects: what it does, cost, refunds, cancellation, and async behavior. The main gap is that it doesn't state what the response contains (e.g., a batch/task ID) or how to track completion, though the async framing and sibling names image_batch_status and image_batch_result make this inferable.

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%, so the baseline is 3. The description adds meaningful semantic context beyond the schema: it binds image_count to the cost formula (장수×25포인트), explains mode covers both generate and edit, and clarifies the async behavior of the whole operation. This goes beyond what the schema's brief field descriptions provide, though it doesn't enumerate individual parameter details.

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 (접수합니다 - accepts/submits), resource (이미지 대량 작업 - bulk image tasks), and scope (1~50 images, async, generate or edit). It clearly differentiates from the single-image siblings image_generate and image_edit by emphasizing the batch and asynchronous nature, so an agent can tell them apart without opening the 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?

The description implies usage context through '1~50장의 비동기 생성 또는 편집 작업' (bulk, async, 1-50 images), which signals when to prefer this over single-image tools, and the async wording implies pairing with image_batch_status/image_batch_result. However, it never explicitly names alternatives, states conditions for choosing this tool, or says when not to use it.

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 provide readOnlyHint=true; the description adds the key behavioral constraint that only completed jobs are valid and that the output is image content. It does not contradict annotations, though it remains silent on error behavior for invalid indexes or incomplete jobs.

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 that conveys the action and condition without unnecessary words. The '[무료]' note is extra but minimal and does not detract from clarity.

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 simple read-only tool with fully described parameters and a clearly stated return type (image content), the description is sufficiently complete. It does not detail edge cases like index-out-of-range, but that is already constrained by schema maximum/minimum and does not impede 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?

Both parameters have schema descriptions (job_id as '작업 ID' and index with 0-based semantics and min/max), giving 100% schema coverage. The description adds no parameter-specific detail beyond what the schema already documents, so 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 ('반환합니다') and a precise resource ('완료된 대량 작업 결과 중 지정한 한 장'), clearly indicating it retrieves one image from completed batch results. This differentiates it from creation or status siblings, making its purpose unmistakable.

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 usage when a batch job is completed ('완료된'), but it does not explicitly state when to use this tool over alternatives like image_batch_status or image_batch_create. No direct exclusions or alternative referrals are provided.

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=true, and the description adds useful behavioral context beyond that: it surfaces billing-related state (pre-deduction, refund, current deduction points) and marks the operation as [무료]. This helps the agent understand what kind of read operation it is and what domain information is involved, with no contradiction to the 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 a single, front-loaded sentence that names the resource, the action, and the key returned information. The [무료] note is compact and informative, and there is no redundant wording.

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 one simple parameter, readOnly annotations, and no output schema, the description reasonably covers what the tool returns by listing progress status and point-related fields. It does not enumerate possible status values or error behavior, but for a 1-parameter status query this is a minor gap rather than a significant 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?

The schema has 100% coverage for the single required parameter job_id, including its format pattern and description, so the description does not need to compensate. The description adds no extra semantic detail about job_id itself, which is appropriate given the high schema coverage.

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 (조회합니다, 'queries') and a precise resource: the status of batch image jobs, including progress and point-deduction details like 선차감, 환급, and current deducted points. This clearly differentiates it from sibling tools such as image_batch_create and image_batch_result, 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?

There is no explicit when-to-use guidance or mention of alternatives. The intended use—checking the status of a batch image job by job_id—is implied by the description, but the description does not tell the agent when to prefer this over image_batch_result or when it is not appropriate.

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?

The description adds useful behavioral context beyond the annotations: it advertises the cost (25 points per image) and clarifies the output is returned as image content. Annotations already cover idempotency and non-destructive behavior, so the description's additional pricing and return-type disclosure is meaningful and non-redundant.

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 core purpose, and the cost sentence is useful. However, the pricing information is repeated unnecessarily ('장당 25포인트입니다' and '[이미지당 25포인트]'), introducing minor 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 a tool with six parameters, a complete schema, and annotations covering idempotency and safety, the description provides enough context: core operation, single-image scope, return type, and pricing. There is no output schema, but the description adequately states that the result is image content. Explicit guidance on sibling alternatives is missing, but that is already penalized under usage guidelines.

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%, so the input schema already documents all parameters including prompt, image_url, size, background, output_format, and idempotency_key. The description only restates the two core parameters ('원본 이미지' and '편집 지시') without adding new semantic detail, which matches the baseline 3 for high schema coverage.

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 clearly states a specific action: editing a single image using an original image and an edit instruction, and returning image content. The phrase '한 장' (one image) differentiates it from batch-oriented siblings like image_batch_create, and the editing framing distinguishes it from image_generate.

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 the use case: you have an original image and an edit instruction and want one edited image back. However, it does not explicitly say when to prefer this tool over image_generate or the batch tools, nor does it mention any exclusions or alternative conditions.

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?

The description adds useful behavioral context beyond the annotations: it states the output is a new image, clarifies that the reference image is only reference material, and discloses the cost of 25 points per image. This complements the annotations readOnlyHint=false and idempotentHint=true without contradicting them.

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 first sentence states the core function, the second clarifies the reference-image behavior, and the third gives cost. The only minor redundancy is repeating the 25-point cost in brackets after already stating it in prose.

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 covers the key operational details: single image generation, reference image purpose, new-image output, and cost. It relies on the schema for parameter details, which is appropriate given 100% schema coverage. It does not describe the return payload, but the output-schema absence is partially mitigated by the clear statement that a new image is produced.

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%, so the baseline is 3. The description adds meaningful semantics for reference_image_url by explaining that it is used to understand product, person, color, and composition, and that the result is a newly created image. It also clarifies that the prompt can be used alone or with a reference image.

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 clearly states the action ('generate one image') and the resource, explicitly noting 'one image' (한 장) to distinguish from the batch sibling. It also explains that the result is a new image, which differentiates it from an editing operation like image_edit.

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 gives clear usage context: text alone or reference image plus text, and describes the reference image's role. However, it does not explicitly mention when not to use this tool or name alternatives such as image_edit or image_batch_create, so it stops short of full routing 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 declare readOnlyHint=true, but the description states '토큰 사용량에 비례해 포인트가 차감됩니다' (points are deducted in proportion to token usage), which is a state-changing side effect. This directly contradicts the readOnly hint. The statelessness information is useful, but the contradiction overrides any positive transparency contribution.

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 main purpose is front-loaded and the stateless protocol explanation is compact. However, the second sentence repeats the same idea in Korean, and the trailing '[무료]' tag after the point-deduction warning is confusing. Not every sentence 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?

Given 8 parameters and no output schema, the description covers the essential calling protocol: select a model, send the full history, reuse compacted_messages, and expect point deduction. Error cases and output shape are not described, but 'assistant reply' plus the detailed input schema make correct invocation reasonably achievable.

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 the parameter descriptions for model, messages, content, speed, compact, max_tokens, and temperature are already detailed. The description reinforces the compacted_messages reuse pattern and model lookup, but these are also expressed in the schema's parameter descriptions, so it adds minimal new value.

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 clearly states it sends a chat request to a selected LLM model and receives the assistant reply, with both English and Korean wording. The verb-object pair is specific and unambiguous. It does not explicitly differentiate itself from sibling tools like text_polish or text_summary, so it stops short of a 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 gives strong operational context: the server is stateless, full history must be sent via messages, compacted_messages should be reused for the next turn, and models can be looked up with llm_models. However, it never states when to use llm_chat versus the specialized text_polish/text_summary alternatives, or when not to use it, so usage selection 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?

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: it is free, returns everything in one response ('한 응답에 포함합니다'), and enumerates the fields included. No contradiction with annotations exists.

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 front-loaded with the main purpose, but it repeats information in English and Korean ('List available text-generation LLM models' / '텍스트 생성 모델 카탈로그를 반환합니다') and duplicates the free indicator as '무료입니다' and '[무료]'. Useful details remain, but the repetition keeps it from being tighter.

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, so the description compensates by listing the returned fields: pricing, family, size, multimodal flag, tags, use_cases, and max_context. It also states the intended relationship to llm_chat. Minor gaps like filter combination behavior and exact output shape are acceptable for a simple read-only catalog 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?

Schema description coverage is 100%, with each parameter already documented with its allowed values (e.g., tag as 'reasoning'|'coder'). The description does not add meaning beyond the schema; this matches the baseline of 3.

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 opens with a specific verb and resource: 'List available text-generation LLM models with per-token pricing and max context.' The Korean portion adds concrete output contents, and the tool is clearly distinct from siblings like llm_chat, image_generate, and text_polish.

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 explicitly states when to use this tool: 'llm_chat Tool의 model 입력값을 찾을 때 사용합니다' (use it when finding the model input for the llm_chat tool). It provides clear context but does not explicitly describe when not to use it or name alternative catalog tools.

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 mark the tool read-only and closed-world; the description adds the 100,000-character ceiling, server-fixed model/parameters, latency optimization, and per-request point cost. It doesn't describe the return format, but for a simple transformation this is adequate 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?

The function is front-loaded and the length is manageable, but the English and Korean sentences largely duplicate the same message, and the bracketed point cost is redundant with the preceding sentence. Several sentences repeat information without adding new guidance.

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 single-parameter transformation tool with a fully documented schema and read-only annotations, the description covers the input limit, operation, and cost model. The absence of an output schema is offset by the obvious return of polished text, though an explicit return description would make it fully complete.

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 input schema covers 100% of parameter meaning with its own description of the text field, so the baseline is 3. The description repeats the character limit but adds no unique parameter-level semantics beyond the schema.

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 action (polish), a specific resource (input text), and the concrete transformations (grammar, spelling, awkward phrasing, sentence order) while preserving meaning. This clearly differentiates it from the sibling text_summary, which would condense rather than polish.

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 context in which to use the tool is implied: when a text needs grammar/spelling/phrasing corrections. However, it never explicitly contrasts with alternatives or states when not to use it (e.g., text_summary for summarization), so the routing burden is left to the agent.

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 provide readOnlyHint=true, and the description adds meaningful behavior beyond that: the model/parameters are server-fixed, responses are optimized for speed, and points are deducted per request regardless of token count. It also discloses the 100-point cost, which is useful operational 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?

The English first sentence is clear and front-loaded, and the cost/model details are compact and useful. However, the Korean sentence largely repeats the same information as the English sentence, adding redundancy without substantial new content.

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 simple one-parameter, read-only summarization tool, the description is largely complete: it specifies the input limit, output language, server behavior, and cost. There is no output schema, but the return value is implied as the Korean summary text. Minor details like behavior when the limit is exceeded are not specified, but this is not critical.

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 input schema already describes the only param, text, with its 100,000-character limit, so schema description coverage is 100%. The description repeats the limit but adds little new parameter semantics beyond clarifying the output is Korean. Baseline 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 states a specific verb ('Summarize'), a clear resource ('long text up to 100,000 characters'), and a concrete output ('concise Korean summary'). This clearly distinguishes it from image and chat siblings, though it does not explicitly differentiate it from the closely related text_polish tool.

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 explicit guidance is given about when to use this tool versus alternatives such as text_polish or llm_chat. The purpose is inferable, but there are no stated exclusions, prerequisites, or routing rules to help an agent choose between text_summary and text_polish.

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