Skip to main content
Glama

AI Skill Store

by io.github.garasegae

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
NameRequiredDescriptionDefault
job_idYes
api_keyNo
claim_tokenNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

All AI Skill Store toolsInspect
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.9/5.0
Disambiguation4/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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness3/5

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.

Resources