AI Skill Store

get_vetting_result

Get 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 여부 + 결과 포함)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`job_id`	Yes
`api_key`	No
`claim_token`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: authentication options (api_key or claim_token), polling behavior with is_done flag and retry guidance, and the expected return fields (vetting_status, findings[]). This gives a complete behavioral contract beyond what annotations would provide.

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

Conciseness5/5

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

The description is well-organized with clear sections for purpose, authentication, return behavior, and arguments. Despite being bilingual, every sentence contributes value, and the core purpose is front-loaded. The structure makes it easy for an agent to extract relevant information.

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

Completeness5/5

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

The tool is complex with polling and two auth modes, but the description covers all essential aspects: what it does, when to use it, how to authenticate, what to expect in the response, and how to handle incomplete results. The output schema exists, yet the description still summarizes the key return fields, making it self-sufficient.

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

Parameters5/5

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

Schema coverage is 0%, but the description explains all three parameters: job_id as the vetting_job_id from upload responses, api_key as developer key limited to the uploader, and claim_token as an alternative from draft uploads. This adds significant meaning beyond the raw schema definitions.

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 states 'Get the detailed security vetting report for a skill (poll by job_id, claim_token supported)', which clearly specifies the verb, resource, and the polling mechanism. This distinguishes it from sibling tools like check_vetting_status by emphasizing 'detailed report' and the official path.

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 description provides clear context: it is the official recommended path for agents to receive final results over HTTP without email, and explains when to poll (if is_done=false) and typical durations. However, it does not explicitly name alternative tools or state when not to use this tool, so it lacks full 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?