AI Skill Store

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: it's a public read operation ('공개 조회', no authentication required), and it checks statuses related to claim processes and email verifications. However, it doesn't mention potential rate limits, error conditions, or response formats beyond the status summary. This is good but not exhaustive for a tool with no annotation coverage.

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 appropriately sized and front-loaded: it starts with the core purpose, followed by usage guidelines, args, and returns in a structured format. Every sentence adds value—no repetition or fluff. The bullet points in the usage section enhance readability without wasting space.

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 moderate complexity (single parameter, status checking), no annotations, and an output schema present (implied by 'Returns' section), the description is largely complete. It covers purpose, usage, parameters, and returns. However, it could benefit from more behavioral details like error handling or response structure, but the output schema likely addresses return values, keeping it sufficient.

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 schema description coverage is 0%, so the description must compensate. It adds meaning beyond the schema by explaining that 'claim_token' comes from the 'upload_skill_draft' response and is used to identify the draft. This clarifies the parameter's origin and purpose, though it doesn't detail format or constraints. With one parameter well-contextualized, it compensates adequately for the low schema coverage.

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's purpose: 'Draft Upload 로 올린 스킬의 상태를 공개 조회합니다 (인증 불필요).' This translates to 'Publicly check the status of a skill uploaded via Draft Upload (authentication not required).' It specifies the verb ('check status'), resource ('skill uploaded via Draft Upload'), and scope ('publicly, no authentication'), distinguishing it from siblings like 'check_vetting_status' or 'get_skill' which likely involve different resources or authentication needs.

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 includes an explicit '사용 시점:' (Usage timing) section with three bullet points detailing when to use this tool: to check if a user completed authentication via a claim URL, if an agent-level verification email was processed, or if a draft was claimed/expired within 30 days. This provides clear context and distinguishes it from alternatives, such as 'upload_skill_draft' for uploading or 'get_vetting_result' for vetting status.

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 that API key is required and only accessible to skill owners (implying authentication needs), and mentions the dependency on upload_skill results. However, it lacks details on rate limits, error handling, or what specific states might be returned (though output schema may cover returns).

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 appropriately sized and front-loaded, with the purpose stated first, followed by prerequisites and parameter explanations. It uses bullet-like sections (Args, Returns) for structure, though the formatting could be slightly more streamlined (e.g., integrating Args into the flow).

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 2 parameters, no annotations, 0% schema coverage, and an output schema (which handles return values), the description is mostly complete. It covers purpose, prerequisites, and parameter semantics well, but could add more behavioral context (e.g., error cases or state details) to be fully comprehensive.

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 fully. It adds crucial meaning beyond the schema: version_id is explained as coming from upload_skill results or being a vetting_job_id, and api_key is clarified as a developer key only usable by skill owners. This provides essential context not in 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?

The description clearly states the specific action ('check security vetting status') and resource ('uploaded skill'), distinguishing it from siblings like upload_skill (which uploads) or get_skill (which retrieves skill details). It explicitly mentions 'vetting status', which is unique among the listed 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 provides clear context for when to use this tool: after upload_skill (stating it requires version_id from that result) and for checking vetting status. However, it does not explicitly state when not to use it or name alternatives (e.g., vs. get_skill for general skill info), though the context implies it's specific to vetting.

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 mentions file storage behavior (saves to specified or temp directory) and returns a file path or error, which adds some context. However, it lacks details on permissions, rate limits, side effects (e.g., if it modifies server state), or error conditions beyond a generic mention, making behavioral traits incomplete for a download operation.

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 appropriately sized: a brief purpose statement, key behavior note, and clear sections for Args and Returns. Each sentence adds value without redundancy. However, the Korean text might reduce clarity for non-Korean agents, and some details could be more integrated, but overall it's 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?

Given 3 parameters with 0% schema coverage and an output schema (implied by Returns), the description adds param semantics and return info, compensating partially. However, for a download tool with no annotations, it lacks error handling specifics, file format details, or platform conversion implications, making it adequate but with gaps in completeness.

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. It adds meaningful semantics: 'skill_id' is for the skill to download, 'platform' specifies conversion with enum-like options and default behavior, and 'save_dir' indicates storage path with default to temp. This clarifies beyond schema titles, though it doesn't detail format constraints or validation rules for 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 the tool's purpose: '스킬 파일을 다운로드합니다' (downloads skill files). It specifies the verb (download) and resource (skill files), and distinguishes from siblings like 'get_skill' (which likely retrieves metadata) by focusing on file download. However, it doesn't explicitly contrast with 'upload_skill' or other siblings beyond the core action.

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 implies usage context: download skill files, optionally converted for a platform. It mentions that leaving 'platform' empty downloads the original file, providing some guidance. However, it lacks explicit when-to-use vs. alternatives (e.g., when to use this over 'get_skill' for metadata), prerequisites, or exclusions, leaving usage partially inferred.

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 mentions this is for '집계 통계' (aggregate statistics) which implies a read-only operation, but doesn't explicitly state whether it requires authentication, has rate limits, or describes the return format beyond listing fields. The description adds some context about the purpose but lacks behavioral details like error conditions, data freshness, or access 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 appropriately sized with three sentences: purpose statement, usage context, and parameter/return documentation. It's front-loaded with the core purpose first. The Args/Returns sections are structured but could be more integrated. Minor room for improvement in flow, but generally 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?

Given 1 parameter, 0% schema coverage, no annotations, but with output schema (implied by Returns section), the description is reasonably complete. It explains the purpose, provides parameter semantics with example, and documents return fields. For a simple statistics retrieval tool, this covers the essentials, though could benefit from more behavioral context given the lack of annotations.

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 and only 1 parameter, the description compensates well by providing the parameter name 'agent_name' with an example value ('claude-sonnet-4-6') and clarifying it's the agent name. This adds meaningful semantics beyond what the bare schema provides. However, it doesn't explain format constraints or validation rules for the agent_name parameter.

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's purpose: '특정 에이전트가 업로더로 기록된 스킬의 집계 통계' (aggregate statistics for skills recorded with a specific agent as uploader). It specifies the verb ('집계 통계' - aggregate statistics) and resource ('스킬' - skills), and distinguishes it from siblings by focusing on agent-specific author statistics rather than general skill operations. However, it doesn't explicitly differentiate from all siblings like 'get_skill' or 'search_skills' beyond the agent-author focus.

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 implied usage context: '에이전트 빌더 실적 확인용' (for checking agent builder performance). This suggests when to use the tool (for performance evaluation of agent builders), but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools. No explicit guidance on prerequisites or comparisons with similar tools like 'get_skill' is provided.

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 states this is a '공개 조회' (public inquiry), implying read-only access, but doesn't clarify authentication requirements, rate limits, error conditions, or data freshness (e.g., the date '2026-04-23' might be a snapshot). For a statistical tool with zero annotation coverage, this leaves significant gaps in understanding operational behavior.

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 reasonably concise but includes extraneous details like 'D4, 2026-04-23' without explanation, which adds noise. It front-loads the purpose but mixes Korean and English, potentially reducing clarity. The structure with 'Args' and 'Returns' sections is helpful, but the overall flow could be more polished for better readability.

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 moderate complexity (1 parameter, statistical output) and the presence of an output schema (which should detail return values), the description is somewhat complete. It covers the purpose, parameter meaning, and return metrics, but lacks context on usage scenarios, behavioral traits (e.g., performance, errors), and differentiation from siblings. With no annotations, it should do more to compensate.

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 description adds meaningful context for the single parameter 'agent_name', explaining it corresponds to 'X-Agent-Author' and is used to filter drafts by a specific agent. With schema description coverage at 0% (the schema only provides a title 'Agent Name'), the description compensates well by clarifying the parameter's role and equivalence to a header field, though it could specify format constraints or examples.

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's purpose: retrieving claim statistics for drafts uploaded by a specific agent. It specifies the metrics (claim_success_rate, expire_rate) and scope (agent_author's drafts). However, it doesn't explicitly differentiate from sibling tools like 'get_agent_author_stats' or 'check_draft_status', which might have overlapping functionality.

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 minimal usage guidance. It mentions that the tool is for '공개 조회' (public inquiry) and specifies the agent_name parameter, but offers no explicit advice on when to use this tool versus alternatives like 'get_agent_author_stats' or 'check_draft_status'. There's no mention of prerequisites, limitations, or typical use cases.

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 of behavioral disclosure. It states the tool '안내합니다' (guides), implying it's informational/read-only, but doesn't clarify if it requires authentication, has rate limits, or what happens if inputs are invalid. The description lacks details on error handling, response format beyond '단계별 설치 가이드 문자열' (step-by-step installation guide string), or performance characteristics.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by clear 'Args' and 'Returns' sections. Every sentence earns its place by defining parameters and output without redundancy. The structure is efficient and easy to parse.

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 moderate complexity (2 parameters, one required), no annotations, and an output schema present (implied by 'Returns'), the description is reasonably complete. It covers purpose, parameters, and return value. However, it lacks behavioral context like error cases or usage guidelines, which would be beneficial since annotations are absent.

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 description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'skill_id' is a 스킬 ID (skill ID) and 'platform' is a 플랫폼 이름 (platform name) with enumerated values like 'OpenClaw' and 'ClaudeCode'. This compensates well for the schema's lack of descriptions, though it doesn't detail format constraints or examples.

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's purpose: '특정 플랫폼에 스킬을 설치하는 방법을 안내합니다' (guides how to install a skill on a specific platform). It specifies the verb '안내합니다' (guides) and resource '스킬' (skill) with context '특정 플랫폼에' (on a specific platform). However, it doesn't explicitly differentiate from sibling tools like 'get_skill' or 'download_skill', which might provide related but different functionality.

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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'download_skill' (which might download the skill itself) or 'get_skill' (which might retrieve skill details), nor does it specify prerequisites or exclusions. The usage context is implied but not explicitly 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool aggregates data from zero-result queries and returns a ranked list, which is useful behavioral context. However, it lacks details on permissions, rate limits, or potential side effects (e.g., if it's a read-only operation, though implied by 'get'). The description adds value but does not fully compensate for the absence of annotations, leaving some behavioral traits unspecified.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by brief context, and then a structured breakdown of args and returns. Every sentence earns its place without redundancy, making it efficient and easy to parse for an AI 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?

Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is largely complete. It explains the purpose, parameters, and return format (a summarized string with specific fields). Since an output schema exists, it need not detail return values extensively. However, it could improve by mentioning any prerequisites or error cases, but overall, it provides sufficient context for effective use.

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 input schema has 0% description coverage, so the description must compensate. It provides clear semantics for all three parameters: 'days' (recent N days), 'limit' (max return count), and 'type' (with enum values 'keyword', 'capability', 'all'), including defaults and constraints (e.g., max 365 days, max 100 limit). This adds significant meaning beyond the schema, though it could slightly elaborate on 'type' differences. With full parameter coverage, it scores highly.

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's purpose: '지금 가장 수요 있으나 공급되지 않은 스킬 목록 (Most Wanted)' (list of most in-demand but unavailable skills). It specifies the verb ('get' implied by name), resource ('skills'), and scope ('most wanted'), distinguishing it from siblings like 'search_skills' or 'get_skill' which handle different queries or specific skills. The description adds context about being aggregated from zero-result queries, making the purpose specific and well-defined.

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 clear context for when to use this tool: to find skills with high demand but no supply, suggesting it's for identifying opportunities to create and upload skills. It does not explicitly state when not to use it or name alternatives among siblings (e.g., 'search_skills' for general searches), but the implied usage is strong enough for effective guidance without being misleading.

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 states this is a retrieval operation ('조회합니다'), which implies read-only behavior, but doesn't disclose any behavioral traits like authentication needs, rate limits, error conditions, or what happens if the skill_id is invalid. For a tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond its basic function.

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 appropriately sized and well-structured with clear sections for purpose, arguments, and returns. Each sentence earns its place: the first states the purpose, the second explains the parameter with useful context, and the third describes the return value. It's front-loaded with the main purpose and avoids unnecessary verbosity.

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 moderate complexity (single parameter read operation), no annotations, but with an output schema (which handles return values), the description is minimally adequate. It covers the purpose, parameter semantics, and return type at a high level, but lacks behavioral details like error handling or performance characteristics. The presence of an output schema means the description doesn't need to explain return values in detail, but other gaps remain.

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 description adds meaningful context for the single parameter: it explains that skill_id is '스킬 ID' and specifically notes it comes from 'search_skills 결과의 skill_id' (skill_id from search_skills results). This provides practical guidance on how to obtain the parameter value. With 0% schema description coverage and only one parameter, the description effectively compensates by clarifying the parameter's origin and purpose.

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's purpose with a specific verb ('조회합니다' - retrieve/look up) and resource ('특정 스킬의 상세 정보' - detailed information of a specific skill). It distinguishes this from siblings like search_skills (which searches) and download_skill (which downloads), though it doesn't explicitly name these alternatives. The purpose is specific but could be more explicit about 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?

The description implies usage context by mentioning that skill_id comes from 'search_skills 결과의 skill_id' (skill_id from search_skills results), suggesting this tool should be used after search_skills to get detailed information for a specific skill. However, it doesn't provide explicit guidance on when to use this versus alternatives like get_skill_schema or get_install_guide, nor does it state any exclusions or prerequisites beyond the implied workflow.

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 of behavioral disclosure. It states the tool returns schema information including interfaces, I/O schemas, permissions, and capability tags, which adds useful context about the return format. However, it doesn't describe error conditions (e.g., invalid skill_id), rate limits, authentication requirements, or whether it's a read-only operation. For a tool with no annotations, this leaves significant behavioral gaps.

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 appropriately sized: it starts with the core purpose, lists return details, and includes Args/Returns sections. Each sentence adds value without redundancy. However, the Args and Returns sections are brief and could be more integrated, slightly reducing efficiency.

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 has an output schema (context signals indicate true), the description doesn't need to detail return values extensively. It mentions key components like interfaces and permissions, which is helpful. With 1 parameter and no annotations, the description covers the basics but lacks error handling and usage guidelines. For a simple retrieval tool, this is mostly complete but has minor gaps.

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 input schema has 1 parameter (skill_id) with 0% description coverage, meaning the schema provides no semantic information. The description adds a brief note in the Args section ('스킬 ID'), which clarifies the parameter's purpose but doesn't specify format (e.g., string pattern), validation rules, or examples. This partially compensates for the schema gap but is minimal, aligning with the baseline 3 for moderate value addition.

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's purpose: '에이전트가 스킬을 호출하기 위한 전체 스키마를 조회합니다' (retrieves the complete schema for invoking a skill). It specifies the verb '조회합니다' (retrieves) and resource '스킬 스키마' (skill schema), and distinguishes from siblings like get_skill (which likely returns skill metadata) or download_skill (which likely downloads skill code). However, it doesn't explicitly differentiate from get_install_guide or other schema-related tools, keeping it at 4.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid skill_id), exclusions, or compare it to siblings like get_skill or search_skills. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.

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 full burden and does an excellent job disclosing behavioral traits. It explains authentication requirements (api_key or claim_token), polling behavior (retry after seconds if is_done=false), typical processing time (seconds to tens of seconds), and what the return message contains. The only minor gap is lack of explicit rate limit information.

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 clear sections (purpose, authentication, return format, args, returns) and every sentence adds value. The date metadata at the beginning could be considered slightly extraneous, but overall it's efficiently organized with zero wasted text.

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 polling nature, 3 parameters, no annotations, but with output schema, the description provides excellent completeness. It covers purpose, authentication, usage context, parameter meanings, return format, and polling behavior. The output schema handles return structure details, so the description focuses on operational context perfectly.

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 fully compensates by providing rich semantic information for all 3 parameters. It explains job_id comes from upload responses, api_key is for developer accounts (uploader-only access), and claim_token is an alternative from draft upload responses. This goes well beyond 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 clearly states the tool's purpose: '업로드 응답의 vetting_job_id 로 검수 결과를 폴링합니다' (Poll vetting results using vetting_job_id from upload response). It specifies the exact resource (vetting results) and verb (polling), and distinguishes it from siblings like check_draft_status or check_vetting_status by mentioning it's the official recommended path for agents without email.

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 guidance on when to use this tool: '에이전트가 이메일 없이 HTTP만으로 최종 결과를 받는 공식 권장 경로' (Official recommended path for agents to get final results via HTTP without email). It also specifies authentication alternatives (api_key vs claim_token) and when to retry (if is_done=false). This clearly differentiates it from other status-checking tools.

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 of behavioral disclosure. It states that the tool returns a category list, which implies a read-only operation, but it doesn't disclose any behavioral traits such as rate limits, authentication requirements, or potential side effects. For a tool with zero annotation coverage, this is a significant gap in transparency.

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 front-loaded, with the main purpose stated clearly in the first sentence. The second sentence adds minimal but relevant information about the return type. There is no wasted text, making it efficient, though it could be slightly improved by integrating the return information more seamlessly.

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 simplicity (0 parameters, no annotations, but has an output schema), the description is minimally adequate. It states what the tool does and the return type, but lacks behavioral context and usage guidelines. The output schema likely covers return values, so the description doesn't need to explain those, but overall completeness is limited due to missing behavioral and usage details.

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 has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as the description doesn't contradict the schema and the lack of parameters is straightforward.

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's purpose: 'AI Skill Store의 전체 카테고리 목록을 반환합니다' (returns the complete category list of the AI Skill Store). It specifies the verb '반환합니다' (returns) and the resource '카테고리 목록' (category list), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_platforms' or 'search_skills', which is why it doesn't score 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons with sibling tools like 'search_skills' or 'list_platforms'. The absence of usage guidelines leaves the agent without direction on when this tool is appropriate.

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 of behavioral disclosure. It only states what the tool does (returns a platform list) without mentioning any behavioral traits such as whether it's read-only, if there are rate limits, authentication needs, or what format the return value takes. For a tool with no annotations, this is a significant gap in transparency.

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 front-loaded, with the main purpose stated clearly in the first sentence. The second sentence adds minimal but relevant information about the return type. There's no wasted text, though it could be slightly more structured for clarity.

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 that the tool has 0 parameters, 100% schema coverage, and an output schema exists (as indicated by context signals), the description is somewhat complete for its simplicity. However, it lacks details on behavioral aspects and usage context, which are important even for simple tools. The output schema likely covers return values, so the description doesn't need to explain those, but overall completeness is adequate with clear gaps.

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 has 0 parameters, and the schema description coverage is 100% (as there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline for this case. No additional value is required beyond what's already covered by the empty 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?

The description clearly states the tool's purpose: 'AI Skill Store가 지원하는 플랫폼 목록을 반환합니다' (Returns the list of platforms supported by AI Skill Store). This specifies the verb (returns) and resource (platform list) with context about the AI Skill Store. However, it doesn't explicitly differentiate from sibling tools like list_categories, which is why it doesn't reach a score of 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 provides no guidance on when to use this tool versus alternatives. There are sibling tools like list_categories and search_skills that might be relevant for related queries, but the description doesn't mention any context, exclusions, or alternatives for usage. This leaves the agent with minimal direction.

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 full burden and delivers comprehensive behavioral disclosure. It specifies authentication requirements, rate limits (10/hour/IP), modification behavior on recall, ownership restrictions, and mentions the return value ('결과 메시지'). This goes well beyond basic functionality description.

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 purpose statement, authentication note, policies section, and parameter explanations. Every sentence earns its place, though the policy section could be slightly more concise. The information is front-loaded with the core purpose 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?

Given the complexity of a write operation with authentication, rate limiting, and business rules, the description provides complete context. With no annotations but an output schema present, the description covers authentication needs, usage constraints, parameter meanings, and behavioral traits, making it fully adequate for agent understanding.

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 compensates by explaining parameter semantics in the Args section: it clarifies skill_id is for the skill being reviewed, rating is 1-5 integer, comment is optional with 2000 character limit, and api_key is required for authentication. This adds substantial meaning beyond the bare 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?

The description clearly states the tool's purpose: '스킬에 리뷰(평점 + 코멘트)를 작성합니다' (write a review with rating and comment for a skill). It specifies both the action (write) and resource (skill review), distinguishing it from sibling tools like get_skill or search_skills which are read operations.

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 usage guidelines: '인증된 사용자/에이전트만 가능합니다' (only authenticated users/agents allowed), '한 사용자가 같은 스킬에 최대 1개 리뷰 (재호출 시 수정)' (one review per user per skill, modification on recall), '본인이 등록한 스킬에는 리뷰 작성 불가' (cannot review own registered skills). These are clear when-to-use and when-not-to-use rules.

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 effectively describes key behaviors: email verification is required, API key issuance is delayed for security, and it returns a registration result message. This covers authentication needs and process flow, though it lacks details on rate limits or error handling.

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 with the main purpose, followed by key behavioral details and parameter explanations. Every sentence adds value without redundancy, making it efficient and easy to parse.

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 (account registration with verification), no annotations, and an output schema present, the description is largely complete. It covers the purpose, process, parameters, and return value adequately. A minor gap is the lack of explicit error cases or prerequisites, but the output schema likely handles return values.

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 description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'username' must be alphanumeric, at least 3 characters, and unique, and that 'email' is required for sending a verification link. This compensates fully for the schema's lack of documentation.

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's purpose: 'AI Skill Store 개발자 계정을 등록합니다' (registers a developer account for AI Skill Store). It specifies the action (register) and resource (developer account), but does not explicitly differentiate from sibling tools like 'upload_skill' or 'check_vetting_status', which are related but distinct operations.

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 implies usage context by mentioning email verification and API key issuance, suggesting this is for initial developer setup. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., no mention of prerequisites like checking vetting status first) or when not to use it (e.g., if already registered).

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 describes the search behavior (agent-optimized vs regular search), sorting logic, and default/limit values, which is helpful. However, it doesn't mention potential rate limits, authentication requirements, error conditions, or pagination behavior for results beyond the limit. The description adds meaningful context but leaves gaps in operational transparency.

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 a clear purpose statement, behavioral notes, and a formatted parameter section. Every sentence adds value, though the Korean text might require translation for some agents. The structure is efficient but could be slightly more front-loaded with the core 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 7 parameters with 0% schema coverage and an output schema present (which handles return values), the description does an excellent job explaining parameter semantics and search behavior. It covers the main functionality thoroughly. The only minor gap is lack of explicit guidance on when to choose this tool over sibling alternatives, but overall it's quite complete for a search tool.

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 schema description coverage is 0%, so the description must fully compensate. It provides excellent parameter semantics: it explains what each parameter does, gives examples for capability and platform, clarifies dependencies (category/sort only apply without agent search), and specifies defaults and limits. This goes well beyond what the bare schema provides and makes all 7 parameters understandable.

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 searches for skills in the AI Skill Store, specifying the resource (skills) and action (search). It distinguishes from siblings like 'get_skill' (retrieve specific skill) or 'list_categories' (list categories only), but doesn't explicitly contrast with all siblings like 'check_vetting_status' or 'download_skill'. The purpose is specific but sibling differentiation is incomplete.

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 clear context for when to use certain parameters: it explains that specifying capability or platform triggers 'agent-optimized search (popularity sorting)', and notes that category and sort parameters only apply when agent search is not used. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_skill' for retrieving a specific skill or 'list_categories' for browsing categories without searching.

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. It discloses that an API key is needed for authentication and that ownership is verified automatically, adding useful context. However, it lacks details on rate limits, error handling, or what the upload entails (e.g., file size limits, overwrite behavior), leaving gaps in behavioral understanding.

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 appropriately sized with three sentences and a structured Args/Returns section, making it easy to scan. It avoids unnecessary fluff, though the translation to English could be slightly polished for clarity without adding bulk.

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 has an output schema (which covers return values) and no annotations, the description provides basic purpose and parameter info but lacks depth. For a mutation tool with authentication needs, it should include more on error cases, success conditions, or integration context to be fully complete.

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. It adds meaning by explaining that 'file_path' is the absolute path to a .skill file and 'api_key' is a developer API key, which clarifies parameter purposes beyond the schema's bare titles. However, it does not detail format constraints or examples for the 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 the action ('upload') and resource ('skill file to AI Skill Store'), making the purpose evident. It distinguishes from siblings like 'download_skill' or 'search_skills' by specifying upload functionality. However, it lacks explicit differentiation in terms of scope or constraints compared to similar 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 mentions that an API key is required, which provides some context for prerequisites, but it does not specify when to use this tool versus alternatives like 'register_developer' or 'check_vetting_status'. No explicit guidance on scenarios, exclusions, or comparisons with sibling tools is provided.

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 excels. It discloses critical behavioral traits: policy constraints (e.g., only AI-approved drafts accepted, others deleted), result details (sandbox tier, draft status), authentication flow (agent_secret reuse, email verification), and mandatory agent actions (e.g., no auto-retry, user display requirements). This covers safety, side effects, and operational nuances beyond basic functionality.

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 sections for policy, mandatory actions, args, and returns, making it easy to parse. It's appropriately sized for a complex tool but could be slightly more concise; some details (e.g., specific dates in examples) might be trimmed. However, every sentence adds value, and the front-loaded policy and actions are critical.

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 (7 params, no annotations, but with output schema), the description is highly complete. It covers purpose, usage, behavioral details, parameter semantics, and output handling (e.g., instructs to surface claim_url and instruction to users). The output schema exists, so return values needn't be explained in detail, and the description focuses on actionable guidance, leaving no significant gaps.

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 fully. It adds rich semantics for all 7 parameters: explains agent_author as an identifier sent via header, skill_md as required SKILL.md content, files as optional dict, requirements as optional requirements.txt, contact_email for automatic verification emails, agent_secret for reuse after initial upload, and claim_token for version updates. Each parameter's purpose and usage context are clearly described, far exceeding schema basics.

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 uploads skills in draft mode without API keys, specifying 'Draft 모드로 스킬을 업로드합니다'. It distinguishes from siblings like 'upload_skill' (likely for non-draft uploads) and 'check_draft_status' (for checking status). The verb+resource+scope is specific and well-defined.

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 usage guidelines: it's for draft mode uploads without API keys, with mandatory agent behaviors (e.g., store agent_secret, display claim_url to users). It implicitly distinguishes from alternatives like 'upload_skill' (for non-draft) and 'check_draft_status' (for status checks), though not explicitly named. The detailed policies and agent actions serve as clear when-to-use instructions.

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. It describes the tool's behavior well: it validates compatibility and returns a summary string with compatibility status, missing packages, and installation recommendations. However, it doesn't mention potential side effects, rate limits, authentication requirements, or error conditions that might be important 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 perfectly structured and front-loaded: purpose statement first, then Args section with parameter details, then Returns section. Every sentence earns its place with no wasted words. The bilingual presentation (Korean purpose, English parameter details) is efficient for its intended audience.

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 (5 parameters, nested objects) and the presence of an output schema, the description is quite complete. It explains what the tool does, all parameters, and the return format. The only minor gap is that it doesn't mention potential error cases or edge conditions, but with an output schema, this is less critical.

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 fully compensates by providing excellent parameter semantics. It explains each parameter's purpose with examples (python_version: '3.11.2'), format specifications (installed_packages: {'requests': '2.31.0'} 형태 dict), and enum values (os: 'linux' | 'darwin' | 'windows'). This adds substantial meaning beyond the bare 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?

The description clearly states the specific verb 'validate' and resource 'compatibility between skill and agent execution environment', distinguishing it from siblings like download_skill or get_skill. It specifies the exact scope: checking requirements and platform compatibility before download.

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 explicitly states 'before download' (다운로드 전에), providing clear temporal context for when to use this tool. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools for different scenarios.

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