Server Quality Checklist

Tool Scores

• site_contextA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key behavior: the tool returns scope and jurisdiction, is intended to run early in a chain, and requires the agent to disclose when coordinate results lack confirmed administrative district information. It does not cover error behavior or what happens with invalid or conflicting inputs, but the core behavioral traits are transparently stated.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences with no filler. The core transformation purpose is front-loaded, followed by usage priority and a necessary caveat. Every sentence contributes actionable information, and the structure makes the tool's role immediately understandable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that an output schema exists, the description does not need to explain return values in detail. It covers the input signals, the invocation order relative to other tools, what to do with the results, and a critical estimateness caveat. A slight gap is the absence of guidance for conflicting or incomplete inputs, but for a simple 3-parameter optional tool this is a minor omission.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3 and the description does not need to add much parameter detail. The description does map '지명' to the region parameter and '좌표' to lat/lng, which is helpful context, but the schema already describes each parameter accurately, including the coordinate fallback role. No additional semantic value beyond the schema is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific function: converting place names and coordinates into climate, culture, and jurisdiction conditions. It also positions the tool as the first one to call when geographic references appear, which differentiates it from the sibling tools even without naming a direct alternative. However, it does not explicitly distinguish itself from a specific sibling by name, so it falls just 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage context: when site, region, administrative district, or coordinates are mentioned, call this tool before others, and pass the returned scope and jurisdiction into downstream queries. It also includes a clear instruction about labeling unconfirmed coordinate results as estimates. It does not explicitly mention when not to use the tool or name alternative tools for exclusions, so it is strong but not maximal.

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

• traverseA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral burden. It meaningfully discloses what an empty result means and explicitly states that the tool will not invent order relationships, which is important trust-relevant behavior for an AI agent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: purpose, typical use cases, relation semantics, and empty-result behavior each get exactly one sentence. There is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a traversal tool with an output schema and fully described parameters, the description covers the crucial domain context: what order means, how relations map to prerequisites vs. follow-ups, and how to interpret empty results. It could be slightly more complete by explaining remaining relation types like 'contrasts', but it is sufficient for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 value beyond the schema by explaining the semantic difference between 'requires' (선행 조건) and 'enables' (후속 가능 작업), which is not fully captured by the schema's terse relation description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool follows construction order and precedence relations, with concrete example questions. It is specific enough to distinguish 'traverse' from siblings like answer_why or compare, though it does not explicitly name the closest alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear guidance on when to use the tool ('공정 질문에 쓴다') with concrete examples such as '기초부터 골조까지 순서'. It does not explicitly state when not to use it or name alternatives, but the intended context is well established.

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

• evidence_forA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It does disclose useful output behavior—separating evidence_note from stance and passing disclaimers through—but it does not explicitly state read-only semantics, prerequisites, or error behavior. This is adequate but not fully transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three dense, purposeful sentences: purpose, usage trigger, parameter semantics, and output handling. Every sentence earns its place and there is no redundant filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has four parameters and an output schema, the description covers the core invocation context, parameter semantics, and key output distinctions. It lacks explicit sibling routing and operational caveats, but nothing essential for calling the tool correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3, and the description adds real value on top: it clarifies that from and to are concept names, gives example relation values like causes/enables/requires, and explains as_of for past-as-of queries. This goes beyond the bare schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a concrete action and object: confirming the evidence for one causal link ('A 가 B 를 유발한다'는 한 연결의 근거를 확인한다). It also states the tool is for validating causality in a previous answer, which separates it from sibling tools like path_between or enumerate.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  '앞선 답에 쓰인 인과를 검증할 때 쓴다' provides a clear trigger condition for when to use the tool. It does not explicitly name alternative tools or state when not to use it, but the intended context is unambiguous.

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

• path_betweenA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral burden. It discloses a critical trait: '경로가 없으면 만들어 내지 말고 연결이 확인되지 않는다고 말한다' (do not fabricate a path; report that no connection is confirmed). The verb '확인한다' also signals a read/verification operation. It does not discuss permissions or side effects, but those are less relevant for a graph-query tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short sentences, each earning its place: purpose, usage condition with examples, and the no-fabrication rule. The content is front-loaded and contains no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a graph-query tool with a rich schema and an output schema, the description supplies the key selection condition and the critical negative-result behavior. It is slightly incomplete in not addressing when sibling tools such as answer_why or evidence_for would be more appropriate, but the agent can still call path_between correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3; the schema already documents a, b, scope, and profile. The description's examples illustrate valid values for a and b but add no new parameter syntax or semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: '두 개념이 어떻게 이어지는지 확인한다' (verify how two concepts connect) and gives two concrete examples. The phrase '출발·도착이 분명할 때 쓴다' distinguishes this from broader siblings like traverse or enumerate by requiring clear endpoints.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states when to use the tool: when the start and destination are clear, with examples. It does not, however, name alternatives or state when not to use it, so it stops short of full exclusion guidance.

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

• review_planA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that the input must be parsed structural data, not an image, and guarantees that violations are not omitted from the answer. However, it does not explain how missing data is handled, whether jurisdiction influences the review, or what kind of output format to expect beyond the 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three dense sentences deliver the core action, trigger condition, input semantics, and an output guarantee. There is no fluff or repetition of schema details, and the most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the output schema and complete parameter descriptions, the definition adequately covers what the tool does, when to use it, what to pass in, and how it behaves. The main gaps are the lack of exclusions/alternatives and jurisdiction-related caveats, but these are minor given the structured schema coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 meaning by explaining that rooms, adjacencies, openings, and circulation should be the structure extracted from drawings—and clarifies room attributes like use and exterior-window presence—going slightly beyond the schema's generic descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 reviews floor plans/layouts from a building-code perspective and flags daylight, ventilation, evacuation, and area violations. This clearly distinguishes it from the sibling tools, which focus on paths, comparisons, evidence, or enumeration.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says to use this tool when the user shares drawings or requests spatial-composition review. It does not state exclusions or name alternatives, but the trigger condition is clear and actionable.

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

• k_snippetsA
  4.3/5.0
  Behavior5/5

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

  There are no annotations, so the description carries the full burden of behavioral disclosure. It explains the return format (original clause text plus source identifiers like KDS 14 20 22 §4.3.1), the meaning of relevance=low and lacks_answer=true, and instructs the agent to say den does not hold the material rather than fabricating. It also discloses as_of behavior for historical queries.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, then organized into scannable use-case categories, return semantics, missing-data handling, and historical querying. Though longer than average, each section earns its place and the structure makes it easy for an agent to extract the key guidance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The schema covers all five parameters, and the description covers purpose, when to use it, return format, source citation expectations, missing-data behavior, and historical query semantics. With no annotations and an output schema present, nothing critical is missing for selecting and invoking this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3; the schema already documents question, as_of, limit, scope, and profile in detail. The description adds only a small amount of behavioral context around as_of and scope, but does not materially improve parameter understanding beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  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: it finds original numeric text and clause wording from Korean construction standards (KDS, KCS, KS) and building laws, and gives four concrete example categories. It is clear what the tool does, but it does not explicitly distinguish this tool from sibling tools such as compare, enumerate, or traverse, so it does not fully meet the 5-level criterion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit use contexts with concrete examples ('철근 피복두께', '이어치기 면 처리') and instructs to use this tool before web search when grounding answers. It does not provide exclusions or mention when sibling tools would be more appropriate, so it is clear context without explicit alternatives.

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

• answer_whyA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It adds meaningful context about output semantics: relevance=low or no_path_reason means the den does not contain that path and should not be cited. It does not elaborate on other behavioral aspects, but the output schema partially fills that gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three compact sentences deliver the core purpose, example usage, a complementary-tool pointer, and an important result-interpretation caveat. Every sentence earns its place, and the main action is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the moderate complexity (5 parameters, output schema present), the description covers the essential intent, example usage, and a key limitation. Slightly more explicit differentiation from other siblings would make it fully complete, but nothing critical is missing for invoking the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by giving realistic example questions that clarify the expected form of the 'question' parameter, going beyond the schema's one-line 'Natural-language why question'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: explaining architectural 'why', principles, and pros/cons as causal paths. Concrete examples ('왜 콘크리트에 양생이 필요한가') anchor the purpose, and the mention of k_snippets for numeric/legal content helps distinguish it from at least one sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says to use this tool for reason-seeking questions and advises calling k_snippets when numeric/legal content is needed. It also warns not to use low-relevance/no-path results as evidence. However, it does not explicitly contrast with other closely related siblings like evidence_for or path_between.

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

• emotional_paletteA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and discloses key behavioral traits: it reads transitions, requires spaces in actual traversal order, and is not applicable to work evaluation. It does not describe output behavior, but an output schema is present and covers that gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short sentences deliver the function, usage context, parameter constraint, and a negative case. The core behavior is front-loaded, and every sentence earns its place without filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter tool with full schema coverage and an output schema, the description covers purpose, ordering, experiential target, and an explicit non-use case. No critical information needed to invoke this tool correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3, but the description adds meaning by insisting spaces be in actual movement order rather than any ordering, and by framing the target as the 'experience goal' in the examples. This modestly enhances the schema's existing parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description leads with a specific verb and resource: it 'reads the atmosphere transition' across spaces in sequence. It also bounds the tool's scope with concrete use cases and explicitly excludes work evaluation, which differentiates it from siblings like answer_why.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear when-to-use conditions: when there is a movement order and an experiential goal, with examples like 'compression to release'. It also states a when-not condition for artwork evaluation, though it only implicitly points to the sibling answer_why rather than naming an alternative tool explicitly.

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

• compareA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries full behavioral burden and does so strongly: it states the operation is deterministic, that no LLM is involved, what the result will contain, and that low a_coverage/b_coverage signals thin knowledge and must be reported honestly rather than fabricated.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence earns its place: purpose, invocation condition, return structure, determinism, and honesty policy. The most decision-relevant information is front-loaded before the examples, and there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a rich output schema, so return values need not be fully re-specified; the description still summarizes them. It also covers when to use it, when not to, input flexibility, determinism, and how to handle low coverage—leaving no practical gap for an agent selecting or invoking this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and the schema already documents a ('A vs B' can be passed at once) and b (optional when a contains vs). The description adds contextual examples but does not materially deepen parameter semantics beyond the schema, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('대조한다' – contrasts) and a specific resource ('두 공법·개념의 차이'), and distinguishes itself from scenario by explicitly assigning single sequence to scenario. Concrete examples make the matching intent unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit call conditions ('비교/차이 요청에 호출하라') and an explicit exclusion ('단일 순서는 scenario'), naming the sibling tool that should be used instead. The examples make positive matching easy.

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

• feedbackA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does so thoroughly: it discloses that raw conversation text is never sent, that summaries are limited to 200 characters, that satisfaction must not be inferred, and that a counterfactual phrase must never be invented. It even explains the downstream consequence of the data and the distinction between 'using den' and 'changed because of den'.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but front-loaded with the core purpose and organized with star-bulleted rules for the delicate comment requirements. Some repetition occurs around not guessing or inventing the counterfactual phrase, but this emphasis is purposeful for a tool where hallucinating feedback would be harmful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity, the absence of annotations, and the need to capture nuanced user feedback ethically, the description is complete: it covers purpose, invocation timing, parameter selection rules, content restrictions, and downstream use. Since an output schema exists, not describing the return value is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema already covers all parameters, the description adds critical relational meaning: query_id is preferred over question_text as a fallback, issue_type is only recorded when dissatisfied, satisfied=true requires an adoption line in comment, and the counterfactual part is only included when the user actually stated it. These conditional rules cannot be inferred from the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description defines the tool precisely as a 'relay tool' that records the user's reaction (correction, complaint, adoption, ignoring) after the calling agent uses the prior Den response, and it explicitly contrasts itself with a user-facing form. This verb+resource+scope framing makes its role distinct from the sibling Den answer tools even though it never names them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states when to record ('대화 종료 전', after the preceding Den response) and gives explicit when-not guidance: do not guess satisfaction if no observable reaction exists. It also defines mapping rules from user behavior to satisfied/issue_type, though it does not explicitly name an alternative tool for comparison.

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

• scenarioA
  4.7/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full behavioral burden. It discloses determinism and, crucially, the honest-fallback behavior: low ordering_coverage or gaps mean the graph lacks order knowledge, so the agent must not fabricate and should pass gaps to the user. This is valuable context beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two dense, well-organized sentences: core behavior first, usage routing second, behavioral caveat last. Every clause earns its place; there is no filler or repetition of schema content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With a full output schema and complete parameter documentation in the schema, the description covers purpose, invocation criteria, algorithm, and gap-handling behavior. An agent has everything needed to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so both parameters are already fully documented. The description reinforces the query type with examples but adds no new semantics beyond the schema for max_nodes or query format; baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific action ('constructs a process scenario'), resource ('related process nodes'), and method ('topologically sorts with enables/requires edges') to return an ordered step flow. It also distinguishes itself from k_snippets by clarifying that simple facts belong there, making sibling differentiation clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says when to call: for sequence/scenario requests such as 'construction order from foundation to 3rd floor' and 'temporary works procedure'. It also names the alternative for simple facts (k_snippets), providing a clear routing rule.

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

• enumerateA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description carries the full behavioral burden and does so thoroughly: it states determinism, that the response is a complete member list from an authoritative curated taxonomy, that definitions are pulled from the graph, that gaps honestly signal missing graph data, and that the agent must not fabricate content. It even discloses the fallback behavior for non-curated topics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact yet information-dense: purpose, examples, sibling routing, fallback, and honesty guarantees all appear in a few sentences. Core intent is front-loaded before caveats, and no sentence is redundant with the schema or output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter tool with an output schema and no annotations, the description covers everything needed: what it returns, how it behaves, when to call it, how to distinguish it from siblings, fallback behavior, and how to interpret gaps. There are no material gaps that would prevent correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single query parameter, so the baseline is 3. The description adds value beyond the schema by defining the accepted query pattern ('X의 종류/체계/구성요소') and clarifying the match=None case that affects behavior, which helps the agent form valid inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a precise verb-and-resource combo: completely enumerate the kinds/components/classifications of an entity, with concrete examples like '건축물 하중의 종류'. It also differentiates itself from siblings by explicitly routing ordering to scenario and comparison to compare, so the agent can select it correctly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use criteria ('X의 종류/체계' requests), names alternatives for other request types (scenario, compare), and specifies the fallback to k_snippets when match=None. This is clear routing guidance rather than leaving usage to inference.

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