AI Skill Store

check_draft_status

Check 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 등).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`claim_token`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It adds behavioral context by including '공개 조회' (public inquiry) and listing possible return statuses (claimed, expired, agent_verify_email_sent, agent_claimed). It does not disclose side effects, but as a read-only status check, the public nature and status summary are sufficient.

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

Conciseness4/5

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

The description is well-organized with clear sections for usage, arguments, and returns. It is not overly long, though the bilingual repetition (English and Korean) adds slight verbosity. The front-loaded purpose statement ensures immediate understanding.

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

Completeness4/5

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

For a simple tool with one parameter and an output schema, the description covers purpose, usage scenarios, parameter origin, and return statuses. It is complete enough for an agent to invoke it correctly, and the output schema removes the need to detail return formats.

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

Parameters4/5

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

Schema has 0% description coverage, but the description compensates by explaining that 'claim_token' comes from the 'upload_skill_draft' response. This adds essential meaning beyond the bare schema, clarifying the token's origin and usage.

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

Purpose5/5

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

The description opens with a clear, specific statement: 'Check the status of a draft skill upload using a claim_token.' It names the exact resource (draft skill upload) and action (check status), and the Korean 'Draft 스킬 상태 공개 조회' reinforces this. It distinguishes itself from siblings like check_vetting_status by focusing on draft upload status, not vetting.

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

Usage Guidelines4/5

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

The '사용 시점' section lists three concrete scenarios: checking if a human clicked the claim_url, verifying agent-level verify email processing, and confirming claim/expiry within 30 days. This clearly describes when to use the tool, though it does not 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.

All AI Skill Store tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0

Disambiguation3/5

Several tool pairs overlap in purpose: check_vetting_status vs get_vetting_result both query security vetting, and get_agent_author_stats vs get_agent_identity_stats both provide agent statistics. Though descriptions are detailed and clarify differences, the similar names and overlapping functionality create potential selection confusion.

Naming Consistency4/5

Tool names follow a consistent lowercase snake_case verb_noun pattern (e.g., search_skills, upload_skill, get_skill). Minor inconsistency exists between check_* and get_* for related status operations, but overall convention is clear.

Tool Count4/5

With 18 tools, the server is moderately comprehensive, covering search, upload, download, vetting, reviews, and platform compatibility. This is slightly above the typical 3-15 well-scoped range but not excessive given the store's multi-faceted domain.

Completeness3/5

Core lifecycle is mostly covered: registration, upload, search, retrieval, download, review, and vetting. However, there are notable gaps—no update or delete operations for uploaded skills, and no method to fetch existing reviews, only post them.

Resources

Need Help?