Skip to main content
Glama

Create a saved skill

create_skill

Create a reusable saved skill from a parameterized prompt template with {{variable}} tokens and default parameters; set the kind to generate video, UGC, or image output.

Instructions

Create a reusable saved skill: a parameterized prompt template (use {{variable}} tokens) plus default params. kind selects what running it generates: video, ugc, or image (agent skills are not runnable via run_skill).

Input Schema

NameRequiredDescriptionDefault
kindYes
nameYesHuman-friendly skill name.
slugNoOptional URL-safe slug (auto-derived from name).
descriptionNo
defaultParamsNoDefault request params merged at run time (e.g. model, aspectRatio, count, brandId, useDefaultBrand).
promptTemplateYesPrompt template with {{variable}} tokens.

Output Schema

NameRequiredDescriptionDefault
skillYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare this is a non-readonly, non-destructive, closed-world write. The description adds genuinely non-obvious behavior beyond that: agent-kind skills are inert with respect to run_skill, and defaultParams are merged at run time. It does not discuss persistence, name-slug collisions, or authorization, keeping it below the top score.

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?

Two dense sentences, no filler, and the definition of a skill is front-loaded before the kind semantics. Every clause carries information an agent needs before calling.

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?

With an output schema present, return values need no explanation, and the description covers the two conceptual unknowns (what a skill is, what kind determines). Minor gaps remain around name/slug generation behavior and whether creation is idempotent, but nothing essential to a correct call is missing.

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 coverage is 67%, and the description compensates on the most ambiguous field by explaining what kind actually controls (the generated media type) rather than just listing the enum. It also reinforces the {{variable}} token convention in promptTemplate and the default-params merge semantics, though slug and description are left entirely to the schema.

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?

States a specific verb and resource ('Create a reusable saved skill') and immediately defines what a skill is: a parameterized prompt template plus default params. This clearly separates it from list_skills, get_skill, update_skill, and run_skill without needing the schemas opened.

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?

Explains that kind selects the runnable output type and explicitly warns that agent skills are not runnable via run_skill, which is a real routing constraint between siblings. It stops short of contrasting create vs update_skill or stating prerequisites, so it is clear context rather than a full when/when-not matrix.

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