킷 아이콘 버그 전면 교정 CSS

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.