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

Although annotations already declare read-only, idempotent, non-destructive behavior, the description adds important operational details: empty inputs trigger an isError with field names and examples, and the retry loop is explained. It also discloses component-specific behavior and the full markdown return contents, including guaranteed items, manual checks, assembly instructions, kit behavior, and optional icon CSS.

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 dense but front-loaded: purpose first, then input requirement, component categories, sibling alternatives, and return format. Every sentence carries actionable information, and there is no filler.

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 read-only component retrieval tool with no output schema, the definition explains the input preconditions, error recovery, component-specific behavior, sibling routing, and return structure. An agent has enough information to invoke it correctly and interpret the response.

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 100%, so the schema already documents componentId, variant, and inputs thoroughly. The description still adds value by clarifying that inputs must contain required fields, that missing fields cause an isError response, and that field names come from list_components.

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 specific verb and resource: it returns the markup and accessibility requirements for one KRDS component. It also distinguishes the tool from siblings by naming get_page_scaffold, get_requirements, and list_components as separate purposes.

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 usage conditions: fill required inputs or receive an isError response guiding the missing fields, then retry. It also routes agents to get_page_scaffold for page structure, get_requirements for requirements only, and list_components for ids, variants, and field names.

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 readOnly/idempotent annotations already cover the safety profile, yet the description still adds useful behavior: the return is markdown containing cause-and-prescription with code, and omitting framework yields a selectable list instead of an error. Nothing contradicts the annotations; only minor traits (version/scope of the prescriptions) are left unstated.

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?

Roughly four dense sentences, each with a distinct job: what it returns, when to reach for it, where the related detail lives, and the exact return shape. The core purpose is front-loaded and there is no filler.

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?

No output schema exists, but the description compensates by naming the return format (markdown with code) and the no-argument fallback. With the single optional parameter fully documented, an agent has everything needed to call this correctly on the first attempt.

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

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

Schema description coverage is 100%, including the enum meanings and the '비우면 목록' behavior, so the schema already carries the parameter semantics. The description restates the empty-argument fallback but adds no syntax or scoping detail beyond what the schema documents, making the baseline 3 correct.

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: returns a conflict guide for using the kit in React/Next.js, naming the concrete failure mode (kit JS initializes once on DOMContentLoaded and is unaware of client routing). It explicitly hands off a neighboring responsibility to get_component's '킷 동작' section, so an agent can tell the two apart without opening either schema.

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 an explicit trigger ('킷 위젯(탭·아코디언·GNB)이 SPA에서 동작하지 않으면') and an explicit ordering rule ('자체 해법을 발명하기 전에 이 가이드를 먼저 보라'). It also names the alternative destination for per-widget details, so routing in both directions is covered.

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?

어노테이션이 readOnly/idempotent/openWorld=false를 이미 선언하므로 안전성 프로파일은 구조화 데이터가 담당한다. 설명은 그 위에 버그의 성격(경로 중복으로 인한 404)과 반환물의 형태(저장·로드 방법 + CSS 코드 블록)를 추가로 공개해 실질적 가치를 더한다. 다만 출력 스키마가 없음에도 CSS 블록의 크기나 파일명 규칙 같은 세부는 언급하지 않아 5는 아니다.

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?

다섯 문장이 각각 목적·배제조건·사용조건·대안·반환형태라는 서로 다른 역할을 맡고 중복이 없다. 첫 문장에 버그와 산출물이 프런트로드되어 있어 스캔만으로 판단이 끝난다.

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?

1개 파라미터·출력 스키마 없음이라는 낮은 복잡도에 비해 설명이 오히려 충분하며, 언제 쓰고 언제 쓰지 말아야 하는지와 반환물 구성까지 갖춰 호출에 필요한 정보가 빠져 있지 않다.

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?

파라미터가 1개이고 스키마 설명 커버리지가 100%이므로 기준선 3이 적용된다. 설명의 assetBase 관련 서술('킷을 서빙하는 경로와 같아야 한다', 기본값 node_modules/krds-uiux)은 스키마 설명에 이미 있는 내용과 사실상 동일해 추가 의미를 거의 제공하지 않는다.

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?

특정 동사(반환)와 리소스(킷 v1.1.0 아이콘 경로 버그 교정용 전체 페이지 CSS)를 명시하고, 버그의 구체적 증상(img/img 중복, 206곳 404)까지 제시한다. get_page_scaffold·get_component 같은 형제 도구와의 경계도 문장 안에서 직접 밝혀 에이전트가 스키마를 열지 않고도 구분할 수 있다.

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?

'get_page_scaffold(withSiteChrome)를 쓰면 자동 주입되므로 필요 없다'는 사용 배제 조건과 'React 레이아웃처럼 직접 구성하는 프로젝트에서 아이콘이 안 보일 때'라는 사용 조건을 모두 명시한다. 단일 컴포넌트는 get_component 응답에 포함된다는 대안까지 제시해 대안 선택 기준이 완결되어 있다.

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 only declare read-only/idempotent safety; the description adds the error contract (missing pageTitle or required slots produce an isError that tells you what to supply) and the return shape (markdown with page HTML, accessibility-correction notes, assembly instructions). This is exactly the kind of non-schema behavior an agent needs before calling.

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?

Front-loaded with purpose and call ordering, then pattern requirements, then options, then return format. Dense but nearly every sentence carries a decision the agent must make; the long inline enumeration of 13 pattern names is the only bulky stretch, and it earns its place as the selection menu.

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 13-parameter tool with nested objects and no output schema, the description covers the generation workflow, the pattern-vs-empty-scaffold branch, error behavior, and output composition. Rich per-parameter details (siteMenu tree semantics, assetBase defaults) are left to the schema, which already handles them.

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 100%, so every parameter is already documented, and the description's parameter content (pattern list, withSiteChrome assembling banner/header/footer, slot discovery via isError) largely restates what the schema says. It adds the workflow hint that slots should be omitted on a first call, but nothing about syntax or value formats beyond the schema.

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

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

States a specific verb and resource ('KRDS 페이지의 시작 골격을 반환한다') and immediately distinguishes itself from the sibling get_component by establishing call ordering. An agent can tell what it produces (page HTML or include fragments) without opening the schema.

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?

Explicitly says to call this before get_component, to use a named pattern for standard screens (로그인·신청·검색·게시판) rather than hand-rolling layout, and to fill body parts with get_component afterward. Both when-to-use and when-not-to-improvise are 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 already declare readOnly/openWorld=false/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond that by disclosing the shape of the payload (guaranteed items with rationale, items delegated to page level, unresolved questions) and the return format (markdown). It stops short of describing behavior for an invalid or unknown componentId, which would round this out.

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 tightly packed sentences: purpose and scope first, content inventory second, alternative routing and return format last. Every clause carries information and the scope constraint is front-loaded.

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 correctly takes on the burden of describing what comes back, listing the four content categories and the markdown format. For a one-parameter read tool this is nearly complete; only error/unknown-id behavior is unaddressed.

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

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

Schema description coverage is 100% and the single parameter is documented in-schema with both id forms ('krds:button' or 'button') and a pointer to list_components, so the description has little left to explain. The phrase '필수 입력(필드명·규칙)' could be mistaken for parameter guidance but actually describes returned content, so the description adds no parameter meaning beyond the schema. Baseline 3 is appropriate.

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

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

Names a specific verb and resource (접근성 요건 조회 for a single component) and adds the key scope qualifier '마크업 없이', which distinguishes it from the markup-bearing sibling. It also enumerates what the response contains (필수 입력, 보장 항목과 근거, 페이지 위임 항목, 미판정 질문), so an agent knows exactly what kind of answer this tool yields.

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?

States the intended context ('코드 리뷰·설계 검토용') and gives an explicit alternative with the selecting condition: '마크업이 필요하면 get_component를 부른다'. That is a clean when-to-use / when-to-use-something-else pair with no inference required.

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 readOnly/idempotent/non-destructive, and the description adds substantive behavior beyond them: var() references are resolved to concrete values (hex etc.), results cap at 80 items, and a query-less call returns a classification guide rather than erroring. That is real operational context an agent could not infer from the annotations.

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?

Four short sentences, each carrying distinct information: identity, value resolution, usage rule, and return shape. No repetition of the title or schema, and the most decision-relevant facts come first.

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 does so: token name, value, and resolved real value, capped at 80. Combined with 100% schema coverage and full annotation coverage, an agent has everything needed to call this 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 100% and the schema already explains the space-separated AND matching with examples, so the baseline is 3. The description adds meaning the schema does not: omitting query entirely yields a category guide, which tells the agent the parameter is safely optional and how to start exploring.

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 immediately scopes it with examples (색·간격·글자 크기, CSS 커스텀 프로퍼티). This clearly separates it from siblings like list_components or get_component, which deal with components rather than tokens.

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 an explicit when-to-use rule: if custom CSS needs colors/sizes, look up a token here and use var() instead of an arbitrary value, with the accessibility rationale stated. It also documents the no-query behavior. It does not name any alternative sibling tool or state a when-not condition, so it falls short of 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 readOnly/idempotent/non-destructive, so the safety profile is covered; the description reinforces this with '파일을 쓰지 않는다' (no file writes). It also describes the return shape (markdown with title, body font, per-selector layout/color/font/spacing), which goes beyond annotations. Minor gap: nothing on performance/network behavior for fetching URLs, though openWorldHint covers remote access.

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?

Front-loaded with the capability, then alternatives, then return format; every sentence carries weight. Slightly dense with parenthetical examples, but none is wasteful.

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?

No output schema exists, and the description compensates by specifying the markdown return contents. Combined with 100% schema coverage and read-only annotations, an agent has everything needed to call 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 100% and each parameter (url/html/filePath mutual exclusivity, selectors max 20 with example) is already documented in the schema. The description adds little parameter-level semantics beyond reaffirming the tool reads per-selector styled output, so baseline 3 applies.

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 (읽는다/reads) and the exact resources it extracts from a rendered page — computed color, background, font, size, layout, margin/padding/gap, and whether the font actually applied. It is clearly separable from sibling validate_page, which handles accessibility judgment.

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?

Explicitly names the alternative workflows it replaces ('임시 playwright 스크립트를 만들지 말고 이 도구를 쓴다') and routes accessibility/KWCAG checks to validate_page. Both when-to-use and when-not-to-use are 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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral detail — the exact per-line content (id·name, required input count, 필드:, 변형:) and the return format (one markdown list) — which no structured field provides. It stops short of full disclosure only in trivial respects, since a zero-parameter static index has little else to disclose.

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?

Four short sentences, front-loaded with what is returned and followed by the routing rules and return format. No filler, and every sentence carries a distinct piece of information.

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?

Zero parameters, no output schema, and the description compensates by describing the return format and the structure of each line. An agent has everything needed to decide when to call it and how to consume the result.

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. The description goes slightly further than required by explaining how the returned fields map onto get_component's componentId, inputs, and variant arguments, giving the agent a concrete handoff path.

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?

Opens with a specific verb and resource ('사용 가능한 KRDS 컴포넌트 43종의 색인을 반환한다') and even quantifies the corpus size. It immediately distinguishes itself from get_component, get_requirements, and get_page_scaffold by naming each alternative in context.

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?

Explicitly routes the agent: whole-page construction should call get_page_scaffold first instead of this tool, markup needs get_component, and requirements-only needs get_requirements. Both when-to-use and when-not-to-use are stated with named alternatives.

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 destructiveHint=true and readOnlyHint=false; the description earns that by disclosing exactly what is written (per-screen folder with md report, raw json, 2 screenshots, plus SUMMARY.md update) and what is deleted (runs beyond keepRuns). It also discloses a critical caveat: a pass here does not mean audit pass, because automated judgment covers only part of accessibility issues. It further notes the records are read by the Stop hook and gate command, explaining downstream side effects.

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 long and dense, but front-loaded with purpose, then caveat, then invocation timing, then side effects, then the sibling pointer and return shape. Nearly every clause carries decision-relevant content; only the return-format sentence is somewhat compacted into a dense list.

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 8 optional parameters, no output schema, and a destructive, open-world operation, the description supplies what the structured data cannot: artifact layout, gate/hook dependency, retention deletion, ambiguity (pass ≠ audit pass), and the return value's shape (one-line conclusion, delta vs previous, KRDS issues, resource errors, artifact paths, full report). Nothing an agent needs to invoke it correctly 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 coverage is 100%, so the baseline is 3, but the description adds real semantics: url/filePath are preferred because relative-path assets resolve, while html breaks them; keepRuns is framed as deletion of prior run records beyond a retention count. It does not add syntax detail for screen, sourceDir, or actions beyond the schema, so it is informative rather than exhaustive.

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: re-inspect a fully assembled/converted page in a real browser against KWCAG 2.2, running axe-core fully and translating results into 33 KWCAG items, with manual contrast measurement. It also draws the boundary against the sibling inspect_page ('요소 하나의 색·배치·폰트만 확인할 때는 inspect_page'). An agent can identify and distinguish this from all listed siblings without opening any schema.

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 call ordering ('템플릿을 프레임워크로 변환한 뒤, 페이지를 조립한 뒤, 콘텐츠를 채운 뒤에 호출하라'), recommends url or filePath with a reason (relative assets resolve) and reserves html as a last resort. It names the alternative tool and the condition that selects it ('inspect_page'). When and when-not guidance is complete.

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