Agent-first skill marketplace with USK open standard for Claude, Cursor, Gemini, Codex CLI.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 18 of 18 tools scored. Lowest: 3.4/5.
Most tools have distinct purposes, but check_vetting_status and get_vetting_result both deal with security vetting and could be confused. Similarly, get_agent_author_stats and get_agent_identity_stats overlap somewhat, though descriptions differentiate them.
All tool names follow a consistent verb_noun snake_case pattern (e.g., search_skills, upload_skill_draft, get_vetting_result). No mixed conventions or vague verbs.
18 tools is slightly above the typical well-scoped range (3-15), but the coverage of a skill marketplace (search, browse, upload, vet, review, stats, install) justifies the count. It doesn't feel bloated.
Core workflows are covered: search, download, upload, review, and status checks. However, there is no tool to update or delete an uploaded skill, and no way to list skills uploaded by a particular author, which are notable gaps for a marketplace.
check_draft_statusAInspectCheck the status of a draft skill upload using a claim_token. / Draft 스킬 상태 공개 조회.
사용 시점:
- 사람이 claim_url 을 클릭해서 인증을 끝냈는지 확인
- contact_email 로 보낸 agent-level verify 메일이 처리됐는지 확인
- Draft 가 30일 안에 claim 됐는지 / 만료됐는지 확인
Args:
claim_token: upload_skill_draft 응답의 claim_token
Returns:
상태 요약 (claimed, expired, agent_verify_email_sent, agent_claimed 등).
| Name | Required | Description | Default |
|---|---|---|---|
| claim_token | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses the nature of the tool as a status check, mentions the 30-day expiration context, and lists possible return statuses (claimed, expired, agent_verify_email_sent, agent_claimed). This gives the agent a good understanding of the tool's behavior and outcome, though it does not state whether it is read-only or if any side effects occur.
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 usage, arguments, and returns, making it easy to scan. The bilingual presentation adds some redundancy (the first sentence is repeated in Korean), but the usage scenarios are solely in Korean and provide useful detail. Overall, it is concise and 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?
For a simple one-parameter status check tool, the description covers all necessary context: purpose, specific usage scenarios, parameter origin, and return statuses. Although an output schema exists, the description still enriches the return value understanding. It is complete and leaves no major gaps for the agent to infer.
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 only defines claim_token as a string with no description (schema coverage 0%). The description compensates by explaining that claim_token comes from the upload_skill_draft response, which is essential for correct usage. It also implies the token's role in identifying the draft. This adds significant meaning beyond the schema, though it could include an example or format.
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 function: 'Check the status of a draft skill upload using a claim_token.' The verb 'Check' and resource 'draft skill upload' are specific, and the mention of claim_token distinguishes it from sibling tools like check_vetting_status. The Korean subtitle also reinforces the purpose.
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 '사용 시점' (usage scenarios) section explicitly lists three concrete situations for using this tool: checking if a person completed verification via claim_url, if the agent-level verify email was processed, and if the draft was claimed or expired within 30 days. This gives clear context on when to invoke it, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_vetting_statusAInspectCheck the security vetting status of an uploaded skill version. / 업로드 스킬의 보안 검수 상태 확인.
upload_skill 결과에서 받은 version_id와 API 키가 필요합니다.
Args:
version_id: 스킬 버전 ID (upload_skill 결과의 version_id 또는 vetting_job_id)
api_key: 개발자 API 키 (스킬 소유자만 조회 가능)
Returns:
검수 상태 메시지
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | ||
| version_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries a heavier burden. It discloses that the API key is required and that only the skill owner can query ('스킬 소유자만 조회 가능'), and it mentions the source of the version_id. However, it does not explicitly state whether the operation is read-only or has other behavioral traits, leaving some ambiguity.
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 well-structured: a one-sentence purpose, bilingual equivalent, then brief Args and Returns sections. Every part is useful and there is no redundant 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?
The description gives enough context for a two-parameter status-checking tool: it references upload_skill, explains the required inputs, and notes ownership restrictions. The output schema exists, so the minimal 'Returns' message is acceptable. It does not elaborate on more advanced nuances, but for this simple tool it is sufficiently 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?
The schema parameters are bare titles, but the description adds meaningful semantics: version_id is '스킬 버전 ID (upload_skill 결과의 version_id 또는 vetting_job_id)' and api_key is '개발자 API 키 (스킬 소유자만 조회 가능)'. This explains the origin and purpose of each parameter, compensating for the 0% 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 function: 'Check the security vetting status of an uploaded skill version.' This is a specific verb-resource pair that distinguishes it from siblings like check_draft_status (draft status) and get_vetting_result (detailed vetting result).
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 context for when to use the tool: after uploading a skill ('upload_skill 결과에서 받은 version_id와 API 키가 필요합니다'), and it notes that API key is required. It does not explicitly mention when not to use it or name alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
download_skillAInspectDownload a skill package. Specify 'platform' to get an auto-converted package for that platform (ClaudeCode, Cursor, CodexCLI, GeminiCLI, etc.). / 스킬 패키지 다운로드 (플랫폼별 자동 변환).
Args:
skill_id: 다운로드할 스킬 ID
platform: 플랫폼 (OpenClaw, ClaudeCode, ClaudeCodeAgentSkill, CustomAgent, Cursor, GeminiCLI, CodexCLI). 비워두면 원본(.skill) 다운로드.
save_dir: 저장 디렉터리 경로 (비워두면 임시 디렉터리에 저장)
Returns:
저장된 파일 경로 또는 오류 메시지
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | ||
| save_dir | No | ||
| skill_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses key behaviors: platform-dependent auto-conversion, default save directory (temp), and return of file path or error message. It does not detail authentication needs or potential side effects on server state, but for a download tool this is adequate.
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 structured with purpose, arguments, and return sections, making it easy to scan. The bilingual text adds some length but every section provides necessary operational detail; 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?
Covers purpose, all parameters with defaults, and return type, which is sufficient for a moderate-complexity tool with an output schema. It could mention that the download creates local files, but save_dir implicitly conveys that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description supplies all parameter meaning: skill_id, platform with an explicit enum-like list, and save_dir with default behavior. This fully compensates for the empty schema descriptions, including defaults for platform and save_dir.
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?
Description opens with a specific action 'Download a skill package' and clarifies platform auto-conversion, distinguishing from sibling get_skill which likely retrieves metadata but not a package. The mention of original .skill download for empty platform further clarifies scope.
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 that specifying 'platform' yields an auto-converted package for that platform, and leaving it blank downloads the original .skill, providing clear context for how to choose. However, it does not explicitly compare to get_skill or list exclusions, so it is not a full when/when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_author_statsBInspectGet contribution stats for an agent author - uploads, claims, attribution history. / 에이전트 빌더 기여 통계.
Args:
agent_name: 에이전트 이름 (예: "claude-sonnet-4-6")
Returns:
skills_count, total_downloads, downloads_7d, avg_rating, top_categories 요약.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden; it lists return fields but none about side effects, permissions, data freshness, or error behavior. It does not contradict annotations (none), but leaves behavioral traits under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is compact with clear Args/Returns sections and a front-loaded summary. Korean translation adds slight redundancy but is not harmful; no wasted sentences.
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 simple one-param stats tool with output schema, description covers return fields and parameters, but lacks usage context with sibling tools and any preconditions or error cases. Overall adequate but not 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 coverage is 0%, but description provides an Args section with agent_name meaning and example 'claude-sonnet-4-6', compensating for schema's bare string type. For a single parameter, this is sufficient semantic detail.
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?
Description uses specific verb 'Get contribution stats' and lists scope: uploads, claims, attribution history. This clearly identifies the resource and distinguishes from sibling get_agent_identity_stats, which focuses on identity rather than contribution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or exclusions; it simply states what the tool does. Does not mention when to prefer this over get_agent_identity_stats or other stats-related tools, leaving the agent without guidance on choosing between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_identity_statsBInspectGet identity stats for the calling agent - claim success rate, claimed/expired counts. / 에이전트 단위 claim 통계.
특정 agent_author 가 업로드한 Draft 들의 claim_success_rate / expire_rate 를 공개 조회.
Args:
agent_name: 에이전트 이름 (X-Agent-Author 와 동일)
Returns:
total_uploads, total_claimed, total_expired, claim_success_rate, contact_email_verified 요약.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose that this is a '공개 조회' (public query/read-only) operation, which is useful. However, it does not explicitly state that there are no side effects, nor does it clarify ambiguity about whether it is restricted to the calling agent. The return summary is mentioned, adding some 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 bilingual (English and Korean) but both sections are concise and informative. It includes a structured Args and Returns section. The repetition across languages is a minor inefficiency but does not detract significantly; it is well-organized and 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?
For a simple one-parameter stats tool, the description covers the purpose, parameter semantics, and return fields. Although an output schema exists, the description still lists the returned summary fields. It lacks usage context and clarification of the 'calling agent' nuance, but overall it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, but the description compensates well by explaining the parameter 'agent_name' and noting it should match X-Agent-Author. This adds meaningful context beyond the bare schema definition, making it easier for an agent to correctly provide the 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 gets identity stats including claim success rate, claimed/expired counts, and specifically mentions querying drafts by agent_author. There is some ambiguity between 'calling agent' and a generic agent_name parameter, but the purpose is specific enough to distinguish from siblings like get_agent_author_stats.
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 such as get_agent_author_stats or other stats tools. It does not mention any exclusions or prerequisites. The only hint is 'for the calling agent', but the agent_name parameter suggests it can be used for any agent, leaving the intended use case unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_install_guideAInspectGet step-by-step installation instructions for a skill on a specific platform. / 플랫폼별 스킬 설치 가이드.
Args:
skill_id: 스킬 ID
platform: 플랫폼 이름 - 'OpenClaw' | 'ClaudeCode' | 'ClaudeCodeAgentSkill' | 'CustomAgent' | 'Cursor' | 'GeminiCLI' | 'CodexCLI'
Returns:
단계별 설치 가이드 문자열
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | OpenClaw | |
| skill_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the return type ('단계별 설치 가이드 문자열') but does not mention potential errors, permissions, or side effects. For a simple getter, this is somewhat adequate but lacks edge-case 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. The docstring format for Args and Returns is clear and compact, with no unnecessary 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?
The description covers purpose, parameters, and return value. An output schema exists, so return details are less critical. It lacks edge-case or error handling information, but for a simple tool with two parameters, it is reasonably 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?
With 0% schema description coverage, the description fully compensates by explaining both parameters in the Args section, including a list of valid platform values ('OpenClaw', 'ClaudeCode', etc.). This adds meaningful semantic detail 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 function: 'Get step-by-step installation instructions for a skill on a specific platform.' It uses a specific verb ('Get'), a resource ('installation instructions'), and a scope ('for a skill on a specific platform'), effectively distinguishing it from sibling tools like get_skill or get_skill_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?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternatives. However, the specificity of the purpose makes the usage context implicitly clear, so it earns a mid-range score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_most_wantedAInspectGet the list of most-wanted skills that haven't been built yet (Supply Loop). Agents can build these to fill community demand. / 미공급 수요 스킬 목록 (Most Wanted).
0건 검색 쿼리를 집계한 결과 — 여기 올라온 스킬을 만들어 업로드하면 즉시 다운로드 수요 있음.
Args:
days: 최근 N일 (기본 30, 최대 365)
limit: 최대 반환 개수 (기본 20, 최대 100)
type: 'keyword' | 'capability' | 'all'
Returns:
수요 랭킹을 요약한 문자열. 각 항목: query, query_type, zero_result_count, last_seen.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| type | No | all | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool aggregates '0건 검색 쿼리' (zero-result queries), describes the return as a summary string with fields (query, query_type, zero_result_count, last_seen), and notes the supply-loop context. This goes beyond a generic 'get' and provides meaningful behavioral insight, though it omits details like auth or rate limits.
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 Purpose, Args, and Returns sections, and it front-loads the main purpose. The bilingual text (English/Korean) is slightly redundant but not wasteful, and every sentence contributes to understanding the tool's function and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, usage context, parameter semantics, and return format (including each field in the output string). Even without an explicit output schema, the Returns section fully describes the return value. This is complete for a 3-parameter retrieval 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 provides only names and defaults with zero descriptions, but the description's Args section fully explains each parameter: days (recent N days, default 30, max 365), limit (max count, default 20, max 100), and type (enum values 'keyword' | 'capability' | 'all'). This completely compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the list of most-wanted skills that haven't been built yet (Supply Loop).' It uses a specific verb ('Get') and resource ('list of most-wanted skills'), and distinguishes it from sibling tools like get_skill or search_skills by emphasizing unbuilt skills. The Korean translation reinforces the meaning without adding ambiguity.
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 the tool: 'Agents can build these to fill community demand' and explains that the list aggregates zero-result search queries, implying a demand-driven use case. However, it does not explicitly name alternatives or state when not to use this tool, 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.
get_skillAInspectGet detailed info for a specific skill including description, supported platforms, version history, author, and security vetting status. / 특정 스킬의 상세 정보 조회.
Args:
skill_id: 스킬 ID (search_skills 결과의 skill_id)
Returns:
스킬 상세 정보 JSON 문자열
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions that the tool returns a JSON string and lists the types of information included (description, platforms, version history, author, vetting status). This gives agents a good sense of what to expect, though it doesn't cover error cases or authentication 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 concise: a two-sentence purpose statement followed by minimal Args and Returns sections. It is front-loaded with the core function and every sentence adds value, including the Korean translation for multilingual support.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameter source, and return format. Given the tool's simplicity (one parameter, output schema present) this is nearly complete, though it could explicitly differentiate from overlapping siblings like get_skill_schema or get_vetting_result for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining that skill_id comes from search_skills results. This adds meaningful context beyond the schema's simple 'Skill Id' label, helping the agent know how to obtain the correct value.
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 begins with 'Get detailed info for a specific skill' and enumerates specific content fields (description, supported platforms, version history, author, and security vetting status). This clearly identifies the tool's action and scope, distinguishing it from siblings like get_skill_schema or get_vetting_result.
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 Args section states 'skill_id: 스킬 ID (search_skills 결과의 skill_id)', indicating that the skill_id should be obtained from search_skills results. This gives practical usage context, though it doesn't explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_skill_schemaAInspectGet the full schema for invoking a skill - interface spec, input/output schemas, permissions, and capability tags. / 스킬 호출용 전체 스키마 조회.
인터페이스, 입출력 스키마, 권한, 능력 태그 등을 반환합니다.
Args:
skill_id: 스킬 ID
Returns:
스킬 호출 스키마 정보
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the type of information returned (interface spec, I/O schemas, permissions, tags) but does not mention side effects, auth requirements, or that it is a read-only operation. This is acceptable for a simple retrieval tool but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured with a summary, Args, and Returns sections. The bilingual English-Korean text adds some redundancy but remains readable and every sentence contributes useful 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?
With only one parameter and an output schema present, the description is reasonably complete. It states the purpose and the kind of schema returned. It could mention that skill_id is required, but the input schema already declares that. Overall sufficient for a simple 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?
Schema description coverage is 0%, so the description must compensate for the parameter meaning. However, it only says 'skill_id: 스킬 ID' (skill ID), which adds no detail beyond the parameter name and title. It does not explain what a skill ID is or how to find it.
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: 'Get the full schema for invoking a skill - interface spec, input/output schemas, permissions, and capability tags.' It uses a specific verb and resource, and differentiates this from sibling tools like get_skill by focusing on the invocation 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?
The description implies when to use this tool (to obtain a skill's invocation schema) but does not explicitly state when not to use it or mention alternatives. Sibling tools like get_skill exist, but no contrast or selection guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vetting_resultAInspectGet the detailed security vetting report for a skill (poll by job_id, claim_token supported). / 보안 검수 결과 상세 조회.
업로드 응답의 vetting_job_id 로 검수 결과를 폴링합니다.
에이전트가 이메일 없이 HTTP만으로 최종 결과를 받는 공식 권장 경로.
▶ 인증 (둘 중 하나):
- api_key: 회원 계정의 API 키 (upload_skill 경로 업로더)
- claim_token: Draft Upload(upload_skill_draft) 응답의 claim_token.
API 키 없는 에이전트는 이 토큰으로 자신의 검수 결과를 폴링 가능.
반환 메시지에는 is_done 플래그, vetting_status, findings[] 가 포함됩니다.
is_done=false 면 몇 초 후 다시 호출하세요 (보통 검수는 수 초~수십 초 소요).
Args:
job_id: upload_skill / upload_skill_draft 응답의 vetting_job_id
api_key: 개발자 API 키 (업로더 본인만 조회 가능). 없으면 claim_token 필수.
claim_token: Draft Upload 응답의 claim_token (api_key 대안).
Returns:
검수 결과 메시지 (is_done 여부 + 결과 포함)
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| api_key | No | ||
| claim_token | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well. It discloses authentication requirements, the polling nature, retry behavior when is_done=false, and the returned fields (is_done, vetting_status, findings). It also notes the 'official recommended path' and uploader-only access with API key, adding meaningful behavioral context.
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 overview, authentication, return values, and arguments. Though bilingual, each sentence adds value and is front-loaded with the core purpose. No redundancy or filler weakens the message.
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 3 parameters, no annotations, and an output schema, the description covers purpose, authentication alternatives, polling semantics, return shape, and retry timing. It is sufficiently complete for an agent to select and invoke the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does. It explains job_id as the vetting_job_id from upload responses, api_key as the developer key with uploader-only access, and claim_token as the alternative from Draft Upload. It also clarifies that one of api_key or claim_token is required, adding crucial 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 action: getting the detailed security vetting report for a skill by polling with job_id and claim_token. It distinguishes itself as the official recommended HTTP-only path for agents, but it does not explicitly differentiate from the sibling tool check_vetting_status, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: after uploading a skill, poll with vetting_job_id, and provides alternative authentication via api_key or claim_token. It gives clear context and retry guidance but does not explicitly state when not to use it or compare with sibling status-checking tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesAInspectList all available skill categories on AI Skill Store. / AI Skill Store 전체 카테고리 목록.
Returns:
카테고리 목록 문자열
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the return type as '카테고리 목록 문자열' (category list string), indicating a read-only operation. However, it does not explicitly state the absence of side effects or other behavioral details, though for a simple list tool this is minimally adequate.
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 extremely concise, comprising a bilingual statement and a returns line. It is front-loaded and contains no unnecessary information, making every sentence valuable.
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 (zero parameters, no annotations) and the presence of an output schema, the description provides sufficient completeness. It states the return type and the resource scope, which is adequate for the tool's purpose.
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 zero parameters, so the baseline is 4 per the rubric. The description does not need to elaborate on parameter semantics, and the empty schema confirms this.
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 'List all available skill categories on AI Skill Store' with a specific verb and resource. It is distinct from sibling tools, as no other tool focuses on category listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this tool when you need the list of categories. No explicit alternatives or exclusion criteria are provided, but the tool's simplicity and unique purpose make the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_platformsAInspectList all supported platforms (ClaudeCode, Cursor, CodexCLI, GeminiCLI, OpenClaw, CustomAgent, etc.). / 지원 플랫폼 목록.
Returns:
플랫폼 목록 문자열
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 returns a string containing the platform list, which is useful. However, it does not explicitly mention side effects or confirm it is read-only, though the verb 'List' implies a non-mutating operation. The description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with one clear sentence and a Return line. It includes both English and Korean, which is redundant but not wasteful. Every part serves a purpose, and it is front-loaded with the primary action.
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?
This is a simple zero-parameter listing tool with an output schema available. The description is complete for its purpose: it names the action, provides examples, and states the return type. No additional behavioral or parameter context is needed given the tool's simplicity.
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 zero parameters, so the description does not need to explain parameter meanings. The description adds context by listing example platforms, but with no parameters, the baseline score is 4.
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 'List all supported platforms' with specific examples (ClaudeCode, Cursor, CodexCLI, etc.). The verb 'List' and resource 'platforms' are specific, and the resource type distinguishes it from sibling tools like list_categories.
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 does not explicitly state when to use this tool versus alternatives, but the purpose is straightforward: it is a generic list of supported platforms. Usage is implied by the tool's name and description, though no explicit exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_reviewAInspectPost a review and rating for a skill. / 스킬 리뷰 작성.
정책:
- 한 사용자가 같은 스킬에 최대 1개 리뷰 (재호출 시 수정)
- 본인이 등록한 스킬에는 리뷰 작성 불가
- Rate limit: 10회/시간/IP
Args:
skill_id: 리뷰할 스킬 ID
rating: 평점 (1~5 정수)
comment: 코멘트 (선택, 최대 2000자)
api_key: 개발자/에이전트 API 키 (필수)
Returns:
결과 메시지
| Name | Required | Description | Default |
|---|---|---|---|
| rating | Yes | ||
| api_key | No | ||
| comment | No | ||
| skill_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full responsibility for behavioral disclosure. It reveals the update-on-recall behavior, self-review restriction, and rate limiting. It also states the return type ('결과 메시지'). It could mention error cases, but it covers the most important behavioral traits.
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 brief summary, policy bullet points, and a parameter list. It is bilingual but remains scannable and reasonably concise. Every section adds value, though the bilingual duplication slightly lengthens it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with no annotations, the description covers all parameters, key usage policies, and return value expectations. An output schema exists, so detailed return formatting is not required. Minor gaps like error handling are acceptable given the overall coverage.
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 compensates for the input schema's 0% description coverage by explaining each parameter: skill_id, rating (1-5 integer), comment (optional, max 2000 chars), and api_key (필수). However, it marks api_key as 'required' while the schema's required array only lists skill_id and rating, creating a minor inconsistency.
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 clear, specific action: 'Post a review and rating for a skill.' This is distinguishable from sibling tools like upload_skill, search_skills, or get_skill, making the tool's purpose immediately obvious.
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 policy conditions: one review per user per skill, re-calling updates the existing review, self-review is prohibited, and a rate limit of 10/hour/IP. This effectively tells the agent when to use the tool and what constraints apply, though it does not name alternative tools (none are relevant).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_developerAInspectRegister a developer account on AI Skill Store. API key is issued after email verification. / 개발자 계정 등록.
이메일 인증 후 API 키가 발급됩니다 (보안을 위해 즉시 발급되지 않음).
Args:
username: 사용할 username (영문/숫자, 3자 이상, 중복 불가)
email: 인증용 이메일 주소 (필수 — 인증 링크가 발송됨)
Returns:
등록 결과 메시지. 이메일 인증 후 API 키를 받을 수 있습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| username | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that API key is not immediate, requires email verification, and specifies username uniqueness constraints. No annotations exist, so the description carries the full burden and does so well.
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?
Description is organized with summary, Args, and Returns sections, front-loading the core purpose. Bilingual text adds some redundancy but every section contributes useful 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?
Covers core behavior, prerequisites, username rules, email purpose, and return message. An output schema exists (though not shown), so the description need not detail return fields. Sufficient for a low-complexity registration 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?
Description provides detailed constraints for both parameters: username format/length/uniqueness, email purpose and verification link. Schema has no descriptions (0% coverage), so this added meaning is essential and thorough.
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?
Description states 'Register a developer account on AI Skill Store' with a specific verb and resource, clearly distinguishing from sibling tools focused on skills, drafts, and reviews.
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?
Clear context: registration requires username and email, with API key issued after email verification. No explicit alternatives, but siblings don't overlap with registration, so the intended use is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_skillsAInspectSearch skills on AI Skill Store. Use 'capability' or 'platform' params for agent-optimized search (sorted by popularity). Returns skill name, description, downloads, rating, and trust level. / AI Skill Store에서 스킬 검색.
capability나 platform을 지정하면 에이전트 최적화 검색(인기순 정렬)을 사용합니다.
Args:
query: 검색 키워드 (스킬 이름 또는 설명). 비워두면 전체 목록.
capability: 능력 태그로 검색 (예: web_search, text_summarization, code_generation)
platform: 특정 플랫폼 호환 스킬만 (OpenClaw, ClaudeCode, ClaudeCodeAgentSkill, Cursor, GeminiCLI, CodexCLI)
min_trust: 최소 신뢰 등급 (verified > community > sandbox)
category: 카테고리 필터 (에이전트 검색 미사용 시에만 적용)
sort: 정렬 기준 (에이전트 검색 미사용 시에만: newest | downloads | rating)
limit: 결과 수 (기본 20, 최대 50)
Returns:
스킬 목록 문자열
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | newest | |
| limit | No | ||
| query | No | ||
| category | No | ||
| platform | No | ||
| min_trust | No | ||
| capability | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses return content (skill name, description, downloads, rating, trust level) and the popularity-sorted behavior for agent-optimized search, along with limit constraints (default 20, max 50). However, it doesn't discuss auth or error conditions, which are less critical for a read-only search.
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?
Structured into summary and argument sections; the bilingual English/Korean text adds length but is organizationally clear. The repetition between languages is somewhat redundant but not excessive for a 7-parameter tool.
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 7-parameter complexity and no annotations, the description covers parameter semantics, return value summary, and special search modes. It relies on the output schema for exact return structure, which is acceptable.
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 is the only source of parameter meaning. It gives Korean explanations for each parameter, including examples for capability/platform, trust level hierarchy, sort options, and limit bounds, fully compensating 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 'Search skills on AI Skill Store' with a specific verb and resource. It distinguishes this search tool from siblings like get_skill and list_categories by emphasizing search behavior and result contents.
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?
Provides explicit guidance on when to use capability/platform parameters for agent-optimized search, and notes that category and sort apply only when not using agent search. It doesn't name alternative tools, but offers clear context for parameter selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_skillAInspectUpload a skill package to AI Skill Store. Requires an API key. / 스킬 업로드 (API 키 필요).
※ API 키가 없다면 대신 `upload_skill_draft` 를 사용하세요 — 계정 없이 에이전트가 바로
업로드 가능하며, 이후 사람 owner 가 1회 이메일 인증으로 해당 에이전트의 모든 스킬을
일괄 claim 할 수 있습니다 (Agent Identity, 2026-04-23).
**사용 방식 A — JSON content 모드 (에이전트 권장, 디스크 불필요)**:
- skill_md (필수): SKILL.md 전체 내용 문자열
- files (선택): {파일명: 파일내용} 딕셔너리. 예: {"main.py": "import sys\n..."}
- requirements (선택): requirements.txt 내용 문자열
- author_agent (선택): {"name": "...", "provider": "..."} 또는 그냥 name 문자열
**사용 방식 B — 파일 경로 모드 (기존 호환)**:
- file_path: 업로드할 .skill 파일의 절대 경로
둘 중 하나만 제공. 둘 다 있으면 JSON content 모드 우선.
Args:
api_key: 개발자 API 키 (필수). 없으면 upload_skill_draft 를 사용할 것.
file_path: (방식 B) .skill 파일 경로
skill_md: (방식 A) SKILL.md 내용
files: (방식 A) {파일명: 텍스트내용}
requirements: (방식 A) requirements.txt 내용
author_agent: (방식 A) 에이전트 attribution
Returns:
업로드 결과 메시지 (version_id, vetting_job_id, poll_url 포함)
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | ||
| api_key | Yes | ||
| skill_md | No | ||
| file_path | No | ||
| author_agent | No | ||
| requirements | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the API key requirement, the two distinct usage modes, and the return fields (version_id, vetting_job_id, poll_url), implying an async vetting process. However, it does not explicitly state side effects such as whether the skill is immediately public or if an existing skill gets overwritten.
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 lengthy but well-organized with labeled sections and bullet points, and it front-loads the core purpose and prerequisite. Some redundancy exists from bilingual repetition and the detailed Korean note, but each part is informative.
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, the description covers prerequisites, two usage modes, parameter relationships, return values, and an alternative tool. The presence of an output schema means return type details are already provided structurally, so the description is 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 coverage is 0%, but the description thoroughly explains every parameter: `api_key` is required, `file_path` is for mode B, and `skill_md`, `files`, `requirements`, `author_agent` are for mode A with examples. It also clarifies the mutual exclusivity and precedence, fully compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Upload a skill package to AI Skill Store' with a specific verb and resource, and clearly distinguishes it from `upload_skill_draft` by noting the API key requirement and pointing to that alternative.
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 explicitly tells the agent to use `upload_skill_draft` if no API key exists, and details two mutually exclusive usage modes (A: JSON content, B: file path) with precedence rules. This is exemplary when-to-use guidance with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_skill_draftAInspectUpload a skill without an API key (zero-friction). Returns a claim_token to track status. Perfect for agents contributing skills autonomously. / API 키 없이 Draft 모드로 스킬 업로드.
▶ 정책:
- AI 검수(approved)만 수락, 그 외(caution/pending/rejected)는 즉시 삭제.
- 결과는 sandbox tier + claim_status='draft'. 사람 owner 가 claim 해야 community/검증 경로 진입.
- 동일 agent_author 의 모든 Draft 는 한 번의 이메일 인증으로 일괄 claim 됨.
▶ 에이전트 필수 동작(MANDATORY — 무시 시 반복 업로드/인증이 실패):
(1) 최초 업로드 응답의 agent_identity.agent_secret 값을 반드시 저장하라.
이후 같은 agent_author 로 업로드할 때 agent_secret 파라미터에 동일 값 전달.
저장/재사용 안 하면 AGENT_SECRET_REQUIRED(401) 로 차단됨.
(2) 응답의 claim_url, human_action.instruction, agent_identity 를
사용자(사람)에게 그대로, 링크 형태로 표시하라 (요약·의역 금지).
(3) 에이전트가 대신 claim 을 완료하려 하지 말 것. contact_email/verify 메일은
반드시 사람 owner 의 실제 이메일이어야 함.
(4) human_action_required=true 이면 사용자 응답을 기다려라 — 자동 재시도 금지.
Args:
agent_author: 에이전트 식별자 (X-Agent-Author 헤더로 전송). 예: "claude-sonnet-4-6@anthropic".
같은 이름은 agent_secret 으로만 재사용 가능.
skill_md: SKILL.md 전체 내용 문자열 (필수).
files: {"main.py": "...", "util.py": "..."} 형태의 부가 파일 dict (선택).
requirements: requirements.txt 내용 문자열 (선택).
contact_email: 업로더 사람 owner 의 이메일 (선택, OPTIONAL).
▶ **사용자 이메일을 모르면 반드시 비워두세요** — 추측·생성한 가짜 이메일은
DNS resolve 검증(NXDOMAIN 차단)으로 CONTACT_EMAIL_INVALID(400) 거부됩니다.
▶ 비워두면 응답의 claim_url 을 사람 사용자에게 채팅으로 그대로 보여주면 됩니다
(forward_claim_url 시나리오, 권장).
▶ 사용자가 명시적으로 알려준 실제 이메일이 있을 때만 지정. 지정 시 서버가
verify 링크를 자동 발송 (24시간 만료, 미인증 시 72시간마다 최대 3회 reminder).
▶ 한 번만 지정하면 되며 이후 업로드엔 불필요. verify 링크를 사람이 클릭하면
해당 agent_author 의 모든 Draft 가 그 계정으로 일괄 이전.
agent_secret: 최초 업로드에서 발급된 secret (2회차 이후 필수).
claim_token: 같은 Draft 에 새 버전을 추가할 때만 (선택).
Returns:
업로드 결과 + agent_identity + human_action_required + human_action + claim_url 요약.
사용자에게 claim_url 과 instruction 을 반드시 surface 하라.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | ||
| skill_md | Yes | ||
| claim_token | No | ||
| agent_author | Yes | ||
| agent_secret | No | ||
| requirements | No | ||
| contact_email | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of behavioral disclosure. It discloses critical traits: only AI-approved drafts are accepted, others are immediately deleted; results are sandbox tier with claim_status='draft'; human claim is mandatory; agent_secret must be saved and reused; auto-retry is forbidden; contact_email is DNS-validated; and it specifies error codes like AGENT_SECRET_REQUIRED(401) and CONTACT_EMAIL_INVALID(400).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with headers, bullet points, and numbered mandatory steps. The first sentence is front-loaded with the core purpose, and the bilingual Korean/English sections add some redundancy but also accessibility. Every part conveys necessary operational guidance, so the length is justified.
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 complex tool with a human-in-the-loop claim flow, the description fully covers policy, mandatory agent actions, parameter details, and return value usage. It leaves little to no ambiguity about the multi-step process, making it complete even without relying on the output schema.
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 has zero description coverage, but the description provides rich semantics for all seven parameters—agent_author header mapping and reuse rule, skill_md content string, files dict format, contact_email DNS validation and when to omit, agent_secret lifecycle, and claim_token usage for version updates. This goes far 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?
The description clearly states 'Upload a skill without an API key' with a specific verb and resource, and distinguishes this draft-mode tool from the standard upload via zero-friction and claim_token tracking. It also notes it is 'Perfect for agents contributing skills autonomously', which differentiates from sibling tools like upload_skill.
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 frames when to use the tool: 'without an API key (zero-friction)' and 'Perfect for agents contributing skills autonomously'. It also provides mandatory workflow context and policy details. However, it does not name alternative tools or state explicit 'do not use when' conditions, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_compatibilityAInspectCheck if a skill is compatible with a specific platform before downloading. / 다운로드 전 호환성 검증.
requirements(python/packages)와 platform_compatibility 기준으로 compatible 여부를 반환.
Args:
skill_id: 검증할 스킬 ID
python_version: 에이전트 Python 버전 (예: "3.11.2")
os: "linux" | "darwin" | "windows"
installed_packages: {"requests": "2.31.0"} 형태 dict (선택)
target_platform: 설치 대상 플랫폼 ("ClaudeCode" 등)
Returns:
요약 문자열 (compatible 여부 + 누락 패키지 + 추천 설치 명령)
| Name | Required | Description | Default |
|---|---|---|---|
| os | No | ||
| skill_id | Yes | ||
| python_version | No | ||
| target_platform | No | ||
| installed_packages | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the return format (summary string with compatibility, missing packages, and install commands) and the criteria (requirements and platform_compatibility). It does not mention potential side effects or error conditions, but as a read-only validation tool, this is adequate.
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 sentence, a concise argument list, and a returns section. Though bilingual, the Korean portion directly mirrors the English and does not inflate length. Every line serves a purpose, making it efficient and easy to scan.
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 (5 parameters, one nested object) and the absence of annotations, the description covers purpose, parameters, return format, and usage context. The explicit returns summary and optional parameter notes provide sufficient detail for an agent to invoke 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?
The description provides detailed explanations for all five parameters, including example formats and value ranges (e.g., os: 'linux' | 'darwin' | 'windows', installed_packages: {'requests': '2.31.0'}). Since schema_description_coverage is 0%, this fully compensates and adds significant meaning beyond the raw 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 'Check if a skill is compatible with a specific platform before downloading', using a specific verb and resource. It differentiates from siblings like download_skill and get_skill by explicitly mentioning the 'before downloading' context and the validation criteria.
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 phrase 'before downloading' implies the tool should be used prior to download_skill, providing clear contextual guidance. However, it does not explicitly state when not to use this tool or mention alternative tools for other scenarios, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.