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

No annotations are provided, so the description bears the full burden. It discloses that the tool only outputs flow and basis, not calculations or final judgments, which is a key behavioral boundary. It also mentions the ask-back behavior for ambiguous cases. However, it does not describe what happens on invalid inputs, potential failure modes, or how the output is structured (beyond flow + source), which leaves gaps for an agent.

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 uses a clear format with parameter definitions on separate lines and important notes highlighted with ★. It front-loads the core purpose and then enumerates parameters. Every sentence contributes value, though the mix of usage notes within parameter explanations could be slightly cleaner. Overall 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?

The tool has 6 parameters, no annotations, and an output schema exists (though not shown). The description covers the main flow and source inclusion, and the ask-back behavior. However, it misses the domain parameter entirely, does not explain how shape/method interact or what happens if they are left empty (defaults), and does not describe the output structure beyond 'flow + source'. Given the complexity, it is serviceable but incomplete.

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 must explain parameters. It explains member, shape, method, with_source, and excerpt_chars with examples, but completely omits the 'domain' parameter that appears in the schema. It also gives examples only for member, shape, and method, not for excerpt_chars or with_source (though with_source is boolean and self-explanatory). This is incomplete but covers most 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 it produces a step-by-step design flow for a structural member ('부재의 설계 흐름을 단계별로 낸다') and includes the basis clauses. It distinguishes itself from sibling tools by explicitly limiting its scope to flow and basis, not calculations or judgments. This is a specific verb+resource with clear differentiation.

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?

It provides guidance on when to use this tool vs alternatives: it clarifies that it only handles flow and basis, leaving calculations to the designer, implying other design tools do the heavy calculation. It also warns that if multiple trees exist, it asks back rather than choosing arbitrarily, which is a clear behavioral guideline. However, it does not explicitly name sibling tools or state when NOT to use it for other purposes.

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?

No annotations are provided, so the description carries the full burden. It discloses non-obvious behavior: trees load from two sources, and the user folder takes precedence under identical conditions. This is meaningful for a read-only listing tool. It doesn't describe the returned shape, but an output schema exists to cover that. No destructive behavior applies here; disclosure is adequate but not 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?

Two compact paragraphs with the core purpose front-loaded in the first sentence. Every sentence earns its place: purpose, return fields, data sources, and the precedence rule with bold emphasis. No filler or redundancy.

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

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

For a no-parameter listing tool with an output schema, the description is well-rounded: it states what is listed, the composition fields, the loading locations, and the overriding precedence rule. The only gap is explicit sibling routing (covered under usage_guidelines); nothing essential for invoking a pure discovery tool is missing.

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 zero parameters, there is nothing to document in the schema, so the baseline is 4 and no param compensation is needed. The description appropriately focuses on what the tool yields rather than inputs, listing the compositional fields (부재·단면·설계법·검증상태) that the result set contains.

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+resource ('쓸 수 있는 설계 결정트리 목록' — list of usable design decision trees) and enumerates what it returns (member·section·design method·verification status). The plural name 'design_flows' plus the sibling 'design_flow' (singular) hints at differentiation, though it doesn't explicitly contrast itself with that sibling.

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

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

The description gives useful context about data sources and precedence (user folder `~/.kcsc-mcp/flows/*.yaml` overrides package examples) but offers no when-to-use guidance or routing to alternatives. With siblings like design_flow, design_map, and design_template, an agent gets no help deciding when to list flows versus fetch a concrete flow. The precedence info is behavioral, not usage-specific.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals only that the tool 'shows' a map and produces a list of gaps, implying a read-only view, but it does not state side effects, whether it mutates anything, how complete the analysis is, or what happens when the map is empty. The intent is clear but the behavior is under-specified.

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 verbose and wrapped in layered metaphor ('트리는 하나로 끝나지 않는다', '그 목록이 곧 완성하려면 뭘 더 만들어야 하는가'). The core message — shows tree-to-tree connections and lists gaps — is buried in prose rather than front-loaded, and the poetic framing adds little operational value for an agent.

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?

An output schema exists, so the return value need not be spelled out, and with zero parameters there is no invocation risk. The description conceptually conveys the output (a map plus a list of gaps), which is adequate. However, the metaphor makes the exact semantics fuzzy — '끊긴 곳' is never precisely defined — so an agent's understanding of the tool's deliverable remains somewhat speculative.

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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to document, and schema coverage is trivially 100%. It correctly avoids inventing parameter details, which is appropriate for a parameterless 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?

The description indicates the tool shows a connection map of design trees and lists what connections are missing (끊긴 곳), which conveys a core purpose. However, it is heavily metaphorical ('트리', '약축 트리', '연결 기준') and never states a concrete verb+resource, leaving whether it computes, visualizes, or audits ambiguous. It also does not differentiate itself from nearby siblings like design_flows or design_flow.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternative tools are named. The structural-calc context (weak-axis members, block-shear review) explains domain triggers for the connections being mapped, but never tells the agent under what condition it should select this tool instead of a sibling.

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?

With no annotations, the description carries full burden and largely succeeds: it discloses the side effect (stamping records), the guardrail (only stamps trees lacking records), date defaulting to today, and that the verification criteria snapshot comes from the current API. It also honestly states that rechecking revised standards is left to the designer, not the machine. Missing details like permissions or reversibility, but strong for a non-destructive stamp tool.

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 well-structured with line breaks and bold emphasis, placing the core purpose first and then parameter details. It's concise enough for the complexity, though there is slight redundancy in restating the purpose across the last paragraph (the 'why' is explained twice). Overall 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?

An output schema exists, so return values need no description. The main operational nuances (only stamp records absent, criteria snapshot semantics, interaction with design_validate) are addressed. Minor gaps remain: unspecified error handling or behavior when both path and all_confirmed are supplied, but acceptable for low complexity.

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 compensate, and it does: path, all_confirmed, and date are each explained with default behavior. It also clarifies what the stamped verification criteria means (API-provided version per cited standard). Some ambiguity remains about path format or precedence when both path and all_confirmed are given, but the core semantics are covered.

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 stamps confirmation-time records (검증일·검증기준) into a confirmed tree, and explains the two modes (path vs all_confirmed). It references design_validate to signal relationship, but does not explicitly name what distinguishes it from all siblings, so not 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?

It provides parameter-driven usage (all_confirmed=True applies to all confirmed trees without records), and explains that the records are later consumed by design_validate. However, it never states explicitly when to use this tool versus alternatives, nor gives a 'do not use when' condition; usage is implied rather than stated.

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 are absent, so the description carries the full disclosure burden. It does disclose useful behavior: the method parameter defaults to LRFD when left empty, the output destination path, and that design_validate checks cited clauses for existence. However, it never states whether the tool returns YAML text or writes a file — the phrase 'fill the produced skeleton and put it in' implies user placement but leaves the generation behavior ambiguous.

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 well structured with line breaks, bold highlights, and a ★ marker for the critical default-behavior warning. It is longer than average but every section earns its place: purpose, per-parameter semantics, and the downstream validation workflow. Nothing is redundant, though it could be trimmed slightly.

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 it has an output schema (so return values need no explanation) and 3 parameters all undocumented in the schema, the description covers parameters, default behavior, output destination, and the validation handoff. The only notable omission is an explicit statement of the tool's output form, which the output schema presumably supplies.

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 schema description coverage at 0%, the description must compensate, and it does: each parameter gets a Korean semantic label (member = 부재, shape = 단면, method = 설계법), concrete examples (휨부재, H형강), and a default-value warning for method. This meaningfully exceeds what the bare schema provides.

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 and resource: it produces a decision-tree YAML skeleton for a new member, and states the motivating problem (not being able to start when the format is unknown in an empty folder). This distinguishes it from siblings like design_flow and design_sheet by output type. It stops short of an explicit 5 because it never names a sibling tool it is not, relying on the workflow note referencing design_validate instead.

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 context is explicit: use it when starting a new member and the format is unknown. It also prescribes a concrete follow-up workflow (fill the skeleton, place it in ~/.kcsc-mcp/flows/, then run design_validate). The only gap is the absence of an explicit when-not-to-use statement or named alternative.

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?

With no annotations provided, the description carries the full burden and does well: it discloses that the tool performs an external API check against the standard, that it can operate over the entire user folder when both params are empty (broad-scope behavior), and that check_refs=false trades thoroughness for speed. It implies a non-destructive read/validation role, though it never states whether the tool writes or errors on failure.

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 well-structured and front-loaded: one-line purpose, ★ key capability, parameter explanations, then a bulleted catch list. The final rhetorical sentence ('Trees are written by humans... fabricated clause numbers are the most dangerous') adds motivation but is functional padding rather than essential call-time information, keeping it from a 5.

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?

An output schema exists, so omitting the return format is acceptable. For a validation tool with an API dependency and five distinct detection categories, the description covers inputs, scope behavior, detection scope, and the external-check behavior. The remaining gap is the absence of explicit guidance on which sibling handles adjacent concerns and what happens on validation failure.

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 compensate — and it does. All three parameters (tree_yaml, path, check_refs) receive explicit semantics including the mutual-exclusivity relationship, the default behavior when both are empty, and the meaning of the boolean flag and its performance implication. This goes well beyond the bare schema fields.

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+resource ('inspects a decision tree') and immediately front-loads the distinctive capability via ★: it verifies cited reference clauses actually exist by API call. The 'catches' list (missing schema, duplicate step identifiers, broken branches, fabricated clause numbers, design-method/standard mismatch) precisely distinguishes it from the design_* authoring siblings and kcsc_* retrieval tools.

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

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

The description gives useful in-tool usage guidance: the tradeoff between tree_yaml/path input (both empty → scans all user trees) and the check_refs speed toggle ('turn off = schema only, faster'). However, it never names alternatives or states when NOT to use this tool vs. a sibling (e.g., kcsc_audit or other design_* tools), leaving the selection decision implicit.

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?

With no annotations provided, the description carries the full burden and delivers exceptionally. It discloses the critical limitation that KCSC original formulas are images the tool cannot read, that formulas/coefficients are model-recalled from memory ('모델이 기억으로 채운 것'), and that correctness cannot be distinguished from output alone. It also explicitly separates verified vs. unverified content. This is exemplary epistemic transparency for interpreting results correctly.

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 longer than average but densely functional—every section earns its place: purpose, parameter usage, workflow trigger, image/formula caveat, and the verifies/cannot-verify boundary. Headers and bold formatting aid scanning, and the critical workflow instruction is front-loaded with the ★ marker. Only mild tightening of the caveat section would improve it.

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

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

For a tool with substantial epistemic nuance (image formulas, model-recalled content, correctness boundaries), the description is thorough: it lists what is verified, what cannot be verified, and explains the critical limitation that motivates the tool's existence. An output schema exists, so return-value documentation is covered elsewhere. Nothing essential for correct invocation or interpretation is missing.

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 compensate—and it fully does. It explains 'text' as putting the entire answer text as-is ('전체를 그대로 넣는다') from which citations are extracted, and 'code' as specifying a single standard when it isn't written in the text ('기준이 하나뿐인데 글에 안 적혀 있으면'). Both parameters gain practical usage meaning beyond their bare types/defaults.

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

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

The description opens with a precise verb+resource statement: '계산·검토 답변의 인용을 기계로 검증한다' (machine-verifies citations in calculation/review answers) and enumerates concrete verification targets (standard, clause, formula number, table/figure number existence). The '확인하는 것/확인하지 못하는 것' (what it verifies / what it can't verify) sections clearly demarcate its scope from the sibling searching/reading tools, so an agent can distinguish it without opening schemas.

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 ★-marked instruction gives explicit when-to-use guidance tied to a workflow: '구조계산 답변을 냈으면 이 검증을 함께 돌리고 결과를 밝히세요' (if you produced a structural calculation answer, run this verification and disclose results). The '확인하지 못하는 것' list also implicitly indicates when NOT to rely on it. However, it never names sibling alternatives for exclusion, which is the one gap.

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?

No annotations are provided, so the description carries full burden. It discloses that formulas are GIF images (not text, no alt/MathML), that recognition of subscripts may be faulty, and that the designer performs final cross-checking. It also notes the image numbers match 〔그림 N〕. This is transparent about limitations and output format, though it doesn't state error behavior or auth requirements.

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

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

The description is front-loaded with the core purpose, followed by parameter explanations and a caveat about recognition errors. It is moderately long but every sentence adds value—no fluff. The structure is logical and scannable, though slightly verbose compared to minimal examples.

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 no output schema and no annotations, the description covers the essential operational details: what it returns (image), how parameters work, the numbering convention, and the recognition risk. It could be more explicit about the exact return structure (e.g., an array of image URLs) but the description is sufficient for an agent to invoke 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 coverage is 0%, and the description compensates fully. It explains each parameter: code (기준 코드, e.g., KDS 14 31 10), section (조항번호, must be narrowed), code_type (only when codes overlap), and max_images (max count, 0 default 40). This adds meaning far beyond the schema's bare property names.

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

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

The description clearly states it fetches the section's formula as a 'GIF image' (수식을 이미지 그대로 가져온다), specifying the verb and resource. It distinguishes from text-reading tools by emphasizing the image nature, though it doesn't explicitly name sibling tools. The purpose is unambiguous and easily tells agents when to use it.

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?

It gives specific usage guidance: 'section: 반드시 좁혀서 지정한다' (must be specified narrowly) and explains params like code_type only when codes overlap, and max_images default. It implies when to use this tool (when exact formula images are needed) but doesn't explicitly state when not to use alternatives or contrast with kcsc_read/search. Still, the context is clear.

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?

With no annotations provided, the description carries the full behavioral burden. It discloses that the tool processes entire documents (hence the 10-code limit), that keyword matching requires ALL space-separated words, that table text is included (since standards values are mostly in tables), and that formulas cannot be found. These are significant behavioral traits beyond the schema and are clearly stated.

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?

Despite being in Korean, the description is well-structured with a purpose line followed by clearly labeled parameter explanations. It is information-dense but not bloated; every sentence adds value, and the key limitations (10-code cap, formula unavailability) are front-loaded. The structure aids quick scanning and comprehension.

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 complexity (whole-document scanning, multiple codes, specific matching rules, limitations) and zero annotation coverage, the description is remarkable complete. It covers all parameters, usage conditions, and limitations. While an output schema exists and likely describes the return shape, the description already equips an agent to call the tool correctly in most scenarios.

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 compensate. It does: code is explained as comma-separable with a 10-item cap, keyword is space-separated with AND logic, code_type is 'only when codes overlap', and limit is 'maximum number of clauses'. Each parameter's meaning and usage is defined, which is exactly what an agent needs.

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 precise purpose: find clauses in the standard '본문' (body) that contain a given keyword, and explicitly contrasts itself with the sibling kcsc_search ('kcsc_search가 못 보는 곳을 본다'). This gives a clear verb, resource, and differentiator, so an agent knows exactly what this tool does and how it differs.

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 explicit when-to-use guidance by pointing to where kcsc_search fails, and adds practical constraints: multiple codes are allowed up to a maximum of 10 because it reads whole documents, and it notes the limitation of not searching formulas (which are images). This tells an agent when to prefer this tool and what to expect.

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?

No annotations are provided, so the description carries the full burden. It discloses useful parameter-level behavior (three accepted code formats, the overlap handling for code_type, depth semantics where 3 reaches '4.2.1' and 0/negative means all). But tool-level behavior — such as whether traversal is bounded, pagination, or the shape of the returned hierarchy — is left unstated, though the output schema exists to carry return details.

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 purpose is front-loaded in the first clause, and each subsequent parameter line is terse and information-dense. Every sentence earns its place — there is no filler, duplication, or boilerplate. The format is easily scannable for an agent.

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 3-parameter tool with one required param and an output schema present, the description covers purpose, usage intent, and all parameter semantics thoroughly. Since an output schema exists, the missing return-value prose does not count against it. The only gap is the lack of explicit sibling differentiation, which is a minor omission given the clear purpose statement.

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 compensate, and it does: every parameter gets value-level semantics. `code` documents three accepted input formats; `code_type` explains the 6-digit collision scenario and the KDS/KCS disambiguation; `depth` gives concrete behavior for values 3, 0, and negative. This greatly exceeds the bare schema and leaves nothing about the parameters to ambiguity.

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: '기준의 목차(조항번호 계층)를 낸다' (outputs the table of contents / provision-number hierarchy of a standard) plus the intended use ('choosing which clause to read'). This clearly distinguishes it from siblings like kcsc_read (reads content) and kcsc_search (searches). A slightly more explicit statement of the returned artifact (a hierarchical tree) would push it to 5.

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

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

The description gives a usage context — '어느 절을 읽을지 고르는 데 쓴다' (use it to pick which clause to read) — which implicitly signals it is a navigation/pre-read step before kcsc_read. However, it never names alternatives (kcsc_read, kcsc_search, kcsc_grep) or states when NOT to use it, so routing relies on inference rather than explicit exclusions.

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?

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: tables are preserved, formulas and symbols appear only as figures because the original is an image, and the tool does not invent formulas. It also explains the max_chars default and warns that calculations based on this text are from memory, requiring verification via kcsc_audit. This is comprehensive and honest.

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 well-structured: a brief purpose sentence, parameter explanations in bullet points, and a warning note. Each sentence adds value, but it is slightly longer than necessary. However, the length is justified by the need to explain four parameters with no schema support. Front-loaded with the purpose.

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 complexity (4 params, 1 required), the lack of annotations, and the presence of an output schema, the description covers purpose, behavior, parameter semantics, and usage guidance. It even includes a verification recommendation. An agent can call this tool correctly without additional context.

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 document parameters. It does so thoroughly: code with examples, section with behavior (inclusion of sub-items, default to entire document), code_type with when to use, and max_chars with default. This compensates entirely for the missing schema descriptions.

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 reads the standard original text in clause units, a specific verb and resource. It also adds a distinguishing detail: tables are preserved as tables. This differentiates it from sibling tools like kcsc_search (search) and kcsc_outline (outline) without needing to open schemas.

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

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

The description gives explicit context: it recommends using kcsc_outline to select a clause first, and mentions kcsc_audit for citation verification. While it doesn't explicitly say 'use for reading, not for search', the action 'read' and the parameter explanations imply the intended use. The guidance on when to use alternatives is present but not exhaustive.

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?

No annotations are provided, so the description bears the full burden. It discloses that only name and top-level classification are searched, not body text, and that non-default domains are pushed back in results. It also warns about the implications of using building standards in bridge design. This is extensive behavioral context beyond any 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?

The description is long but every sentence adds value: purpose, parameters, default behavior, exclusions, and a domain warning. It is structured with line breaks for readability and front-loads the core purpose before diving into details. No redundant phrases.

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 complexity (default domain, multiple parameter nuances), the description covers everything an agent needs to select and invoke it correctly: purpose, usage, parameter semantics, behavioral limitations, and alternative routing. An output schema exists, so return format details are unnecessary. Complete for the context.

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 compensate, and it does. It explains that query requires all space-separated words to appear, code_type restricts to listed values, limit sets max count, and domain has a default of '교량' plus special handling for '강구조'. All four parameters are meaningfully described beyond their schema titles and defaults.

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 finds national construction standards by name, listing 3,572 items across KDS/KCS etc. It uses a specific verb ('찾는다' / finds) and resource ('국가건설기준'), and explicitly distinguishes itself from the sibling kcsc_grep (full-text search), so an agent can tell them apart without opening schemas.

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?

It gives explicit guidance: use for name-based search, not for content search (referring to kcsc_grep as alternative). It also explains the domain default behavior ('비우면 교량이 기본'), how to narrow by code_type, and the caution about building standards affecting bridge design. Clear when-to-use and when-not-to-use are present.

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

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

The description discloses a behavioral trait beyond annotations: that the tool fetches a fresh catalog ('카탈로그를 새로 받아 확인하므로'), implying it performs a network read each time—useful for agents deciding between cached vs. fresh data. No annotations are provided, so the description carries the burden, and it does reasonably well by noting this retrieval behavior and its implication for re-verification.

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

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

The description is compact and well-organized: a purpose sentence, a bolded usage hint, parameter notes in a list-like format, and a rationale sentence. Each line earns its place—no fluff or repetition. The most important info (purpose and usage) is front-loaded, with parameter specifics following.

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 this is a simple 2-parameter tool with an output schema present, the description covers the essential points: purpose, parameter semantics, and usage rationale. The note about re-verifying decision-tree basis clauses adds domain context. However, it doesn't explain what the output looks like (the output schema presumably covers this) and assumes domain familiarity with '기준' and '카탈로그', which may be acceptable in a specialized context.

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%, meaning the property names 'code' and 'code_type' carry minimal semantic weight. The description does add some meaning: 'code' is clarified as a 기준 코드 that can take multiple comma-separated values, and 'code_type' is explained as needing specification only when codes overlap ('코드가 겹칠 때만 지정'). This compensates partially for the schema's sparse documentation, but it doesn't clarify the format of code_type or provide examples of valid values.

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+resource: '확인한다' (check/confirm) the version and revision date of a standard ('기준'), and explicitly frames its purpose as checking revision status. It clearly distinguishes from siblings by emphasizing the version-checking role. The opening sentence is clear, but could be more specific about what '기준' entails without relying on the bolded hint.

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 states when to use this tool—when checking whether a standard has been revised ('개정 여부를 확인할 때 쓴다') and to judge whether decision-tree basis clauses need re-validation after receiving a new catalog. This is a clear use case, but it doesn't explicitly mention when NOT to use it or name alternatives among siblings like kcsc_search or kcsc_read. The guidance is contextual but lacks exclusionary statements.

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