APICK OCR

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

Annotations declare readOnlyHint=true, so the read-only nature is known. The description adds practical context beyond annotations: it returns full_text and costs 12 points per call. This is useful, but it doesn't disclose other behavioral traits like language support or error conditions. Given the low bar with annotations, this adds some value but could go further.

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 extremely concise: two sentences plus a cost tag. The main verb is front-loaded, and the cost and scope are mentioned without verbosity. Every element earns its place, making it highly efficient.

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 tool with a read-only annotation, the description covers the purpose, usage context, and return format. It lacks explicit sibling differentiation or output schema, but the output is a simple text string, and the schema is complete. The tool is adequately described 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?

The schema description coverage is 100% for the single parameter image_url, documenting allowed formats and size. The description does not add any extra meaning beyond the schema, so it relies on the schema for parameter details. 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 clearly states the verb 'Extract' and resource 'text from an image', and notes it returns full_text. However, it does not explicitly differentiate from sibling tools like ocr_identi1-5, which appear to be identity-specific OCR. The phrase 'universal images' implies general use but doesn't explicitly exclude identity documents, leaving some inference required.

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 provides context on when to use: 'for universal images such as document photos, scanned images, captured screens.' However, it does not explicitly state when not to use it (e.g., identity documents) or name alternatives. The usage guidance is implied but lacks explicit exclusions or sibling 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?

Annotations already declare readOnlyHint=true, so read-only behavior is covered. The description adds valuable context: it returns structured fields and raw_text, and it discloses the cost (12 points per call). It does not contradict annotations and provides enough behavioral detail for a read-only OCR tool, though it omits details on error handling or invalid-image 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?

The description is concise and front-loaded with the core purpose in the first sentence. However, it repeats the same information in Korean and English, which adds slight redundancy. The cost and legal note are useful and not excessive. All sentences earn their place, though the bilingual duplication could be tightened.

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 OCR tool with no output schema, the description adequately explains the output (structured results + raw_text) and the input (image URL). It also highlights the legal prerequisite, which is critical context. The only missing piece is explicit differentiation from sibling OCR tools, but the specific card-type reference largely compensates.

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 only parameter, image_url, has a full schema description (allowed formats, max 50MB). The tool description adds no additional parameter semantics or constraints. With 100% schema coverage, the baseline of 3 applies; the description does not augment or clarify the parameter 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?

The description clearly states the specific verb ('Extract key fields') and the exact resource ('Korean resident registration card' / 주민등록증), and lists the extracted fields (name, resident registration number, address, issue date). It also specifies the output (structured results and raw text). This specificity naturally distinguishes it from sibling OCR tools aimed at other document types, even without an explicit comparison.

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 provides no guidance on when to use this tool versus sibling tools (ocr, ocr_identi2-5). The only usage note is a legal requirement ('use only when you have legitimate processing basis'), which is about compliance, not tool selection. There is no mention of alternative tools or conditions that would steer an agent toward this specific OCR variant.

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 include readOnlyHint=true, and the description aligns with that. It adds useful behavioral context by stating the return format (structured result and raw_text) and the cost per call (12 points). This goes beyond the annotation without contradicting it.

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—four sentences including the legal note and cost. It front-loads the purpose, then adds necessary context. There is no redundant verbiage, though the bilingual repetition (English and Korean) doubles some content without loss of 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 tool with one parameter and no output schema, the description covers the main necessities: what the tool extracts, the return type, the legal precondition, and cost. It does not enumerate all extracted fields exhaustively, but the '등' (etc.) indicates partiality. Overall, an agent can call this tool correctly with the given information.

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 image_url parameter is fully documented in the schema. The description subtly links the parameter to the document type ('Korean driver license image') but adds no new details about the parameter itself. Baseline 3 is appropriate given 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 the verb 'Extract' and the resource 'key fields from a Korean driver license image', with specific fields listed. It distinguishes from generic OCR by specifying the document type, but does not explicitly differentiate among the closely named siblings (ocr_identi1, 3, 4, 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 provides an explicit usage condition: '정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만 사용하십시오' (use only when legal basis such as consent is secured). This is clear context but does not mention alternatives or when not to use the tool relative to sibling OCR 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 provide readOnlyHint=true and openWorldHint=false. The description adds that the tool returns structured results plus raw_text, and discloses a per-call cost of 12 points. This goes beyond the annotations by describing the output and usage cost, without contradicting the read-only nature. It does not mention error cases or rate limits, but the added context is valuable.

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 sentences with the core action front-loaded in English and a Korean translation adding detail. It is concise and each sentence serves a purpose, though the bilingual repetition is slightly redundant. Overall it is efficient and well-structured.

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 tool with no output schema, the description adequately explains what is returned (structured result and raw_text) and adds important usage constraints (legal basis) and cost. It omits handling of invalid inputs or error responses, but for the tool's simplicity, the provided information is reasonably 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 fully describes the image_url parameter, including allowed formats and size limit. Since schema coverage is 100%, the description adds no additional parameter semantics. The baseline of 3 is appropriate given that the schema carries the full parameter documentation.

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 tool's purpose: extracting key fields (name, passport number, issue/expiry dates, date of birth) from a passport image via OCR. It lists the specific fields and mentions the output format. However, it does not explicitly differentiate this from sibling tools like ocr_identi1 or ocr_identi2 beyond the passport scope, so the purpose is clear but not fully distinguishing.

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 includes a legal-basis condition (only use with consent) and a cost note (12 points per call), but it gives no guidance on when to choose this tool over the sibling OCR tools. It does not mention alternatives, exclusions, or scenario-based selection, leaving the agent to infer that this tool is specifically for passports from the title and description.

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, covering the non-destructive nature. The description adds value beyond this by stating the output format (structured results and raw_text) and a per-call cost of 12 points. It also mentions the legal processing requirement, which is a precondition behavior not captured in annotations. No contradiction detected.

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 relatively short and front-loaded with the core purpose. However, it repeats the same information in English and Korean, which is redundant and slightly wasteful. The additional notes on legal basis and cost are useful but could be more compact. Still, it is efficient enough for an agent to parse quickly.

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 mentions it returns 'structured results and raw_text' but does not specify which 'key fields' are extracted. Since there is no output schema, this lack of detail limits the agent's ability to judge whether the output meets its needs. The tool is simple (one parameter) and the annotations cover safety, but the return value expectations are vague. More specifics about the fields would improve completeness.

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 has 100% description coverage for the single parameter `image_url`, including allowed formats (png/jpeg) and size limit (50MB). The tool description does not add any additional semantic detail about the parameters beyond what the schema already provides. Baseline 3 is appropriate when the schema fully documents parameters.

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 verb 'Extract', the specific resource 'Korean certified copy of resident registration (deungbon)', and the method 'OCR'. It distinguishes itself from sibling tools by targeting a specific document type (deungbon) rather than generic OCR or other document variants. The return of 'structured results and raw_text' further clarifies its scope.

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 for deungbon images and explicitly provides a usage condition: 'Use only if you have secured lawful processing grounds such as consent from the data subject.' However, it does not explicitly compare to sibling tools (e.g., 'use ocr_identi1 for other documents'), leaving the alternative routing implicit. The legal condition adds valuable context for when it is appropriate to invoke.

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, which is consistent with the extract operation. The description adds useful behavioral context beyond the annotation: the per-call cost (12 points), the legal consent requirement, and the return of raw_text in addition to structured fields. This goes beyond what the annotation states.

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 reasonably concise, with the core purpose front-loaded in English and additional detail in Korean. There is some redundancy between the English and Korean sentences, but it remains efficient and no sentence is wasted.

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 OCR tool with no output schema, the description covers the essential: what it extracts, the return format (structured + raw_text), and legal/usage constraints. It is nearly complete, though it could be more explicit about the exact structure of the returned object, but given the simplicity, this is acceptable.

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% — the image_url parameter already includes allowed formats (image/png, image/jpeg) and size limit (50MB). The description adds no extra parameter-specific details, so it adds no value beyond the schema; 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 ('Extract'), a specific resource ('Korean alien registration card image'), and lists the key fields extracted (name, foreigner registration number, issue date). It also mentions returning structured results and raw_text, and the document type clearly distinguishes it from sibling OCR tools for other documents.

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 provides a clear usage condition: only use when lawful processing grounds (e.g., consent) are secured. However, it does not explicitly mention when to use this tool versus the sibling tools (ocr_identi1-4), though the document type is specified, making the selection inferable.

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