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

Beyond the sparse annotations (readOnlyHint=false, destructiveHint=false), the description discloses meaningful behaviors: auto-pagination, deduplication, local file persistence, per-term record caps (50 default, 2500 max), and crucially '클라이언트 후처리' (client-side post-processing) for year and price filters, which tells the agent these filters are applied locally and results may be approximate. This is valuable context well beyond what annotations convey.

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 summary is front-loaded in a single compact Korean sentence, and the parameter section uses a terse 'param: description' format with no redundancy. It is long, but every line is warranted given 13 parameters and zero schema documentation. Minor deduction for the unbroken parameter wall, which could be more scannable.

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 complex 13-parameter, 1-required tool with no output schema, the description covers operation semantics, parameter meaning, output formats, and default output location thoroughly. The notable gap is the return contract: with no output schema, the agent is not told what the tool returns (success message, file paths, record counts) or how failures are reported.

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?

With 0% schema description coverage, the description fully compensates by documenting all 13 parameters with types, allowed values (target, sort, formats), defaults, format constraints (YYYY for years, KRW for prices), and behavioral notes (client-side post-processing). Examples like ['인공지능', '머신러닝'] for terms make correct invocation unambiguous.

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 summary line states a specific verb+resource+mechanism: automatically paginated collection of books across multiple search terms with deduplication, saved to local files. This 'bulk collect and export' profile is clearly distinguishable from the sibling tools (kakao_book_search, kakao_book_status, kakao_book_isbn), which are single-lookup operations.

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 batch use case ('여러 검색어/필터 조건' - multiple search terms/filters) and local-file export, which signals when bulk collection is appropriate. However, it never explicitly names alternatives or states when NOT to use it (e.g., a single ISBN lookup should go to kakao_book_isbn). The usage context is 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 declare readOnlyHint=true, and the description's '조회' (lookup) aligns with that. The description adds the behavioral detail that multiple ISBNs can be specified with commas, which is beyond the schema. It does not contradict annotations, but it doesn't disclose additional traits like return format or rate limits. Given the low complexity and existing read-only annotation, a score of 3 is appropriate.

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: the first states the purpose and format, the second explains the parameter with examples. No wasted words, and the key information is front-loaded. It is appropriately sized for a single-parameter read-only tool.

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 the tool's simplicity (1 param, read-only annotation, no output schema), the description covers the essential details: what it does, how to format the input, and multi-ISBN capability. It does not describe the return format, but for a lookup tool this is often intuitive. The absence of output schema means the agent might benefit from a hint about what fields are returned, but this is a minor gap for such a focused 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 0%, so the description must fully explain the parameter. It does: it defines isbn as the ISBN string, gives two concrete examples, and notes that multiple ISBNs can be separated by commas. This fully compensates for the empty schema descriptions and exceeds the 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?

The description clearly states the tool's purpose: looking up books by ISBN. It specifies the ISBN format (10 or 13 digits, hyphens allowed) and is distinct from sibling tools like kakao_book_search, which likely searches by keyword. The verb '조회' (lookup) and resource '도서' (book) are explicit.

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 you have an ISBN, use this tool) but does not explicitly state when to use it versus alternatives like search. No mention of exclusions or prerequisites beyond the ISBN format. An agent can infer the use case, but it lacks explicit 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 already mark this as read-only/open-world. The description adds meaningful behavioral context beyond the annotations: the external Kakao API pagination cap of 2,500 records (50 pages × 50 items) and the cap_hit=true signal when total_count exceeds that. It does not cover auth, rate limits, or failure modes, but for a read-only search tool this is solid.

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 uses a clear, front-loaded summary followed by one line per parameter and a short warning block. Every sentence conveys necessary operational information, and there is no filler or repetition of the title/schema.

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 five parameters, no descriptions in the schema, and no output schema, the description covers all call parameters, defaults, ranges, and a notable API limitation (cap_hit). It stops short of describing the full return shape and does not discuss when to prefer sibling tools, but nothing blocks an agent from constructing a valid request.

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 0%, so the description carries the full burden for parameters. It compensates well by explaining query, target (with allowed values and default all), sort (accuracy/latest with default), page range, size range/default, and the pagination cap. This adds meaning well beyond the bare schema types.

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 by identifying a concrete action and resource ('카카오 Daum 책 검색 API로 도서를 검색합니다'), and the tool name/siblings make it distinct from status, ISBN, and collect operations. The verb '검색' and the book domain leave no ambiguity about what this tool does.

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 makes it clear that this is the book-search operation and requires a query, but it never names sibling tools or states when to choose search over status/isbn/collect. Usage context is implied rather than explicitly routed, and there are no when-not-to-use 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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that it tests a real round-trip and checks the authentication key, which provides context beyond annotations and is consistent with them. It does not disclose output format but for a status tool that is acceptable.

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 communicates the tool's purpose concisely without any fluff. Every word is informative.

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 zero-parameter diagnostic tool with no output schema and clear siblings, the description is fully sufficient. It explains what the tool does and its scope; nothing is missing 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?

There are no parameters, so the description has no need to explain them. The schema coverage is 100% (empty properties). Baseline of 4 applies because no parameter documentation is required.

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 diagnostic purpose: checking authentication key setup and performing a single round-trip to the Kakao book search API. It is distinct from sibling tools (search, isbn, collect) which all query data; this tool verifies connectivity.

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 'connection check' explicitly signals when to use it (to verify API connectivity and authentication), but it does not name alternatives or state exclusions. The context is clear enough for agents to select it appropriately.

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