Skip to main content
Glama

download_skill

Download 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:
    저장된 파일 경로 또는 오류 메시지

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
platformNo
save_dirNo
skill_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden. It discloses key behaviors: platform-based conversion, default save to a temp directory, and return of a file path or error message. This gives the agent a clear mental model of what happens. Some details like authentication or whether files are overwritten are omitted, but for a download tool, the disclosure is strong.

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 structured with a summary sentence, bilingual text, and an Args/Returns block. It is front-loaded with the main purpose. However, it is slightly verbose because it lists the platform names twice (in the prose and in the Args section). Still, the redundancy is minor and each sentence carries value.

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 tool with 3 parameters and an output schema, the description provides the necessary context: the action, platform conversion options, default save location, and return format. It does not explain potential error scenarios beyond 'error message', but with an output schema available, this is a minor gap. Overall, the description is complete enough for correct selection and invocation.

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?

The input schema has 0% description coverage, but the description explicitly documents all three parameters: skill_id, platform, and save_dir. It explains the meaning and default behavior for each (e.g., '비워두면 원본(.skill) 다운로드' for platform). This fully 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.

Purpose5/5

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

The description starts with a specific verb and resource: 'Download a skill package.' It then distinguishes from siblings by explaining platform-specific auto-conversion (e.g., ClaudeCode, Cursor). The bilingual text clarifies the exact function, so there is no ambiguity about what the tool does.

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?

It clearly states when to use the tool (to download a skill package) and provides the conditional: 'Specify platform to get an auto-converted package for that platform.' It also explains the default behavior when platform is empty. However, it does not explicitly exclude alternatives or mention when not to use it, which would make it a 5.

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.

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