Skip to main content
Glama

Author an Agent Skill (SKILL.md)

skill_author

Author a standard agentskills.io Agent Skill and get back its SKILL.md. A strong skill has: a name in kebab-case (lowercase letters, numbers, single hyphens, ≤64 chars); a description stating WHAT it does AND WHEN to use it, third person, with concrete trigger words (the field agents read to decide whether to load it); and instructions (the Markdown body), specific + imperative, ideally shaped When-to-use → Instructions → Examples → Guidelines. Optional compatibility (runtime/environment requirements, ≤500 chars — set when the skill needs system packages, a language version, network access, or scripts; omit for pure-instruction skills), allowed_tools (a SPACE-separated, least-privilege allowlist with optional scoping, e.g. 'Bash(git:*) Read'), license (a license name or file reference), and metadata (an object of string→string pairs). Returns the assembled SKILL.md to save as SKILL.md in a folder named after the skill. (In the Rokha UI the same tool fills the human's live builder form.)

Input Schema

NameRequiredDescriptionDefault
nameYesSkill id + folder name. kebab-case, ≤64 chars.
licenseNoOptional. A license name or bundled-file reference (e.g. 'MIT').
metadataNoOptional. Arbitrary string→string metadata (e.g. {"author":"example-org","version":"1.0"}).
descriptionYesWhat it does + when to use it. Third person, with trigger words. ≤1024 chars.
instructionsYesThe Markdown body. Specific + imperative. When-to-use → Instructions → Examples → Guidelines.
allowed_toolsNoOptional. SPACE-separated, least-privilege tool allowlist with optional scoping (e.g. 'Bash(git:*) Read'). Experimental.
compatibilityNoOptional, ≤500 chars. Runtime/environment requirements (e.g. 'Requires Python 3.14+ and uv'). Omit for pure-instruction skills.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "type": "object"
      +}
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

With annotations only declaring readOnlyHint=false and destructiveHint=false, the description adds important behavioral detail: it returns the assembled SKILL.md to save in a skill folder and fills the human builder form in Rokha UI. It does not clarify persistence, auth, or rate limits, but it usefully explains that the tool generates output rather than silently writing it.

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 long but front-loaded with the core purpose and organized around the required skill components. Each sentence carries substantive guidance, though the dense single-paragraph format makes it slightly less scannable than ideal.

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 an output schema exists and all 7 parameters are described at 100% schema coverage, the description is complete for authoring a skill: it covers required fields, optional fields, formatting rules, return behavior, and save location. An agent can infer how to call the tool without missing critical context.

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 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining compatibility triggers ('set when the skill needs system packages, a language version, network access, or scripts; omit for pure-instruction skills') and reinforcing allowed_tools scoping and metadata pairs. Some fields are repeated from the schema, limiting the score to 4.

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 first sentence states a specific verb and resource: 'Author a standard agentskills.io Agent Skill and get back its SKILL.md.' This clearly distinguishes the tool from generic publishing or creation siblings, though it does not explicitly differentiate from rig_author or registry_publish.

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

Usage Guidelines3/5

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

The description provides extensive guidance on what makes a strong skill and when to set compatibility, but it does not explicitly say when to use this tool versus alternatives such as rig_author or registry_publish. Usage is implied by 'Author a standard agentskills.io Agent Skill' but no exclusions or sibling routing are given.

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.