Skip to main content
Glama

get_vetting_result

Read-onlyIdempotent
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

NameRequiredDescriptionDefault
job_idYesVetting job ID returned as 'vetting_job_id' by upload_skill or upload_skill_draft.
api_keyNoDeveloper API key of the uploader. Provide either api_key or claim_token; leave empty when using claim_token.
claim_tokenNoclaim_token from upload_skill_draft; alternative to api_key for keyless draft uploaders. Leave empty when using api_key.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / api_key / description
      Added value: +"Developer API key of the uploader. Provide either api_key or claim_token; leave empty when using claim_token."
    • addedInput schema / properties / claim_token / description
      Added value: +"claim_token from upload_skill_draft; alternative to api_key for keyless draft uploaders. Leave empty when using api_key."
    • addedInput schema / properties / job_id / description
      Added value: +"Vetting job ID returned as 'vetting_job_id' by upload_skill or upload_skill_draft."
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

The description goes significantly beyond structured data by explaining the polling workflow (re-call if is_done=false), the expected duration (seconds to tens of seconds), and the specific contents of the response (is_done flag, findings array).

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 definition is necessarily detailed due to the tool's complex nature (polling, dual authentication methods, language requirements). However, it uses clear structural elements (lists, headings, bolding) to remain highly navigable despite the length.

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?

It is exceptionally complete. It covers the 'what', the 'how' (polling), the 'when' (duration), and the 'who' (auth requirements) for this specific workflow.

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?

While schema coverage is 100%, the description is vital in explaining the operational semantics of the authentication parameters. It clearly dictates that `api_key` and `claim_token` are alternatives and specifies which user roles can use which token, adding necessary context beyond simple strings.

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 tool clearly states its purpose: getting the detailed security vetting report. It specifies the core input, the `vetting_job_id`, and explicitly frames it as a polling mechanism for upload/draft responses.

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

Usage Guidelines5/5

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

It provides excellent guidance by stating this is the 'official recommended path' (공식 권장 경로) for agents to receive results via HTTP, implicitly guiding usage over other potential status-checking methods.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources