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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the genuinely useful behavioral fact that the tool is conversational/iterative and that the plan only materializes once next_question becomes null. It does not describe the shape of plan or what happens on malformed input, so the added context is moderate rather than rich.

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 dense sentences, front-loaded with the purpose then the two-phase protocol in chronological order. No filler, though the parenthetical glosses make individual sentences long enough to require a second read.

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 must explain return values — and it does, naming next_question and plan and the termination condition. The remaining gap is the internal structure of plan and the index semantics of the integer arrays, which an agent would still have to discover by calling.

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 carry the parameter burden. It does define the three answer categories (known=설명 가능, confused=헷갈림, asked=넘어감 포함 이미 물어본 것), which is real value, but it never explains that these are integer arrays or how the integers relate to items — the most important ambiguity for actually invoking the tool.

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 the follow-up sentences make the multi-turn diagnostic flow concrete (next_question, then plan). It is clearly distinct from concept-lookup siblings like get_concept or get_prerequisite_path, though it never names or contrasts 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?

Gives unusually concrete call sequencing: first call with items only, then call again with known/confused/asked populated, and repeat until next_question is null. It does not name alternatives or state when a sibling (e.g. rank_shared_prerequisites) should be used instead, which keeps it below a 5.

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=false, so the safety profile is covered and the description only needs to add lookup semantics. It confirms the tool resolves each item to a concept, but says nothing about partial resolution, unknown IDs, or result ordering — behavior an agent would want to know about a batch resolver.

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 sentence with the resource and its accepted formats front-loaded; every clause carries information and nothing is padding.

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 one-parameter, no-output-schema tool, the input side is well covered but the return shape is never described — whether concepts come back parallel to the input list, as a dictionary keyed by item, or with unresolved items flagged. That missing mapping is the main completeness 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 coverage is 0%, so the description must carry parameter meaning, and it does the essential part by enumerating the accepted string formats for `items`. It does not mention that the array is capped at 30 entries or whether mixed formats may be combined in one call, so the compensation is strong but incomplete.

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?

Names a concrete verb+resource pair (returns the concept each exam item asks about) and gives three concrete input formats ('056', '모의1-22', '예시06') that make the item→concept mapping unmistakable. It does not explicitly contrast itself with search_concepts or get_concept, so the sibling differentiation is only implicit.

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?

Usage is implied by the input formats shown: you call it when you have exam item IDs and need the underlying concepts. There is no explicit 'use this instead of X when...' guidance and no statement about what to do with items that don't resolve, leaving the agent to infer 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is already covered. Because no output schema exists, the description carries the return-value burden and does so by enumerating five distinct returned elements, including the immediate predecessor and immediately unlocked concept in the graph. It does not state behavior for a nonexistent id, which is the main remaining 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?

It is a single tightly packed sentence with the resource front-loaded and the returned contents listed afterward, with no filler. The parenthetical unpacking of '정의' adds useful detail at low cost, though the enumeration grows slightly dense.

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 tool this covers the return payload reasonably, which matters since there is no output schema. However, the shape of fields like '중요도' and '출제 정보' remains undefined, and nothing is said about failure when the id does not exist.

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 single 'id' parameter has 0% schema description coverage, so the description should explain what the id identifies and where it comes from (for example, an id returned by search_concepts). Instead it says nothing about the parameter, leaving the agent to infer that it is a concept identifier.

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-plus-resource ('개념 하나의 ... 돌려준다') and enumerates what the single concept record contains: definition rationale, core, calculation reason, importance, exam info, and adjacent concepts in the graph. This clearly separates it from search_concepts, which returns multiple matches. It does not explicitly name a sibling as the alternative, keeping it below 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?

There is no statement about when to use this tool versus search_concepts, get_prerequisite_path, or the other siblings, and no prerequisites such as needing an id from a prior search. Usage is only inferable from the singular 'id'-based shape. No exclusions or routing guidance are 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=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that — results are grouped by depth and L0 is the starting point — but it leaves open whether the traversal is transitive to all ancestors or only immediate prerequisites, and what the grouped return shape looks like despite there being no 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, front-loaded with the core action and followed by the L0 orientation detail. No filler, though the second sentence is terse enough to border on cryptic.

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 and only partially meets it: '깊이별' and 'L0이 출발점' hint at the structure but do not clarify whether L0 is the target concept itself or the first prerequisite ring, nor whether the result is a flat list or nested levels. Adequate to attempt a call, not complete enough to interpret the response confidently.

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 single required 'id' parameter is undocumented in the schema. The description only implies via '개념 하나' that the id identifies a concept, without stating the ID domain, valid range, or behavior on unknown IDs — minimal but not zero compensation.

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: it returns all prerequisite concepts needed to understand a given concept, grouped by depth. This is distinguishable in kind from siblings like get_concept (single concept) and rank_shared_prerequisites, although the description never names those siblings to sharpen the contrast.

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 or when-not-to-use guidance, and none of the closely related siblings (get_concept, rank_shared_prerequisites, find_concepts_for_exam_items) are referenced. The learning-path use case is only inferable from the phrase '개념 하나를 이해하는 데 필요한'.

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=false, so safety is covered. The description adds genuinely useful behavior beyond that: results are limited to the most specific shared prerequisites and are sorted by how many input concepts share them. It does not disclose the cap/truncation behavior, empty-result handling, or the default for the limit parameter.

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 with no filler, stating the result and the ordering rule in one pass. It is efficient, though extremely short given the 0% schema coverage it is compensating for.

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 does explain what comes back conceptually (prerequisite concepts, ranked by shared count), which is the key missing piece. However, for a tool with fully undocumented parameters and no field-level return detail, it still leaves meaningful gaps an agent would need in order to call and interpret it correctly.

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%, with two undocumented parameters (ids: array of 1–30 integers, limit: 1–20), so the description must carry the burden and largely does not. It only hints that several concept IDs are supplied ("개념 여러 개"), giving no indication of what ids accept or what limit controls or defaults to.

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 (돌려준다 / returns) and a precise resource — the most specific prerequisite concepts shared by multiple given concepts — plus the ordering rule (descending by number of sharing concepts). This clearly separates it from siblings like get_prerequisite_path (a path for one concept) and search_concepts (lookup by text).

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 statement of when to use this instead of get_prerequisite_path or search_concepts, and no preconditions or exclusions. Usage is only inferable from the fact that it takes several concepts and returns their common ancestors, which leaves the agent to guess at 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 and openWorldHint=false, so safety is covered. The description adds genuine value by stating the return fields (id, title, importance as 1–5 stars) in the absence of an output schema, but it discloses nothing about match semantics (substring vs. fuzzy), result ordering, or what happens when nothing matches.

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: purpose first, then return shape, then concrete examples. Every element contributes and nothing is padded.

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 two-parameter read-only search with no output schema, the description covers the essentials: what it searches, how to phrase the query, and what comes back. The remaining gaps are the undocumented limit parameter and unstated matching/ordering behavior, both minor but non-zero for an agent tuning result counts.

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 carry the parameter burden. It does so partially for query by framing it as a single word and giving keyword examples, which is real added meaning beyond "type: string", but the limit parameter (1–20) is never mentioned, leaving its purpose and default undocumented anywhere.

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?

"낱말로 개념을 찾는다" gives a specific verb (find) and resource (concepts) plus the search key (a word), which implicitly distinguishes it from get_concept (id-based retrieval). It never names the sibling, so an agent must infer that get_concept is the id-lookup counterpart rather than being told.

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 "낱말로" implies the entry condition: use this when you have a keyword rather than an id. The two examples ("인터럽트", "캐시") reinforce the keyword use case, but there is no explicit when-not guidance and no mention of find_concepts_for_exam_items or other siblings as alternatives.

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