Skip to main content
Glama

unequip_skill

Removes an equipped skill from the active skills folder to free prompt context after a task. Deletes only the specified skill directory and safely returns a notice if it is not installed.

Instructions

Uninstalls and removes an equipped skill from the assistant's active skills folder to clean up environment state and preserve context tokens. Mutating file operation: safely deletes only the specified skill directory from the target skills folder (defaulting to ~/.gemini/config/skills or .agents/skills); leaves all other skills and workspace files untouched. Requires no network access or authentication. If the skill is not installed, safely returns a notice without throwing an error.

When to use: Call when a specialized task is completed and you no longer need the skill instructions in prompt context. When NOT to use: Do not use to delete skills from the permanent offline vault (skills-vault/); this tool only removes temporary equipped copies from the active assistant environment. Returns: Confirmation message stating whether the skill was successfully removed or was not present in the active directory.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "skill_name": "<skill_name>"
    },
    "name": "unequip_skill"
  }
}

Input Schema

NameRequiredDescriptionDefault
skill_nameYesName of the equipped skill folder to remove (e.g. 'taste-skill', 'antislop-ui', 'game-design-studio', 'kubernetes-expert'). Case-insensitive. Required.
target_pathNoCustom destination folder path where the skill was installed. If omitted or empty, automatically resolves to the active global skills directory (~/.gemini/config/skills) or local .agents/skills.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: it declares this is a mutating file operation, bounds the destruction (only the specified skill directory, all other skills and workspace files untouched), states default target paths, notes no network/auth requirement, and specifies idempotent behavior when the skill is absent (returns a notice instead of throwing).

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?

Behavior, scope, when/when-not, and return value are front-loaded in a clearly segmented structure. It runs slightly long — the phrase about cleaning environment state and preserving context tokens is motivational rather than operational — but nothing is genuinely wasteful.

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?

For a two-parameter mutation tool with no output schema, the description covers destruction scope, path defaults, failure/absence behavior, auth requirements, and return value form. Nothing an agent needs in order to call it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented, including case-insensitivity and the default path resolution. The description restates the default skills directories, which adds mild confirmation but no new meaning beyond the schema; the baseline 3 is appropriate.

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 opens with a specific verb and resource: "Uninstalls and removes an equipped skill from the assistant's active skills folder." It also implicitly contrasts with equip_skill and with vault-based tools by scoping itself to temporary equipped copies, so an agent can distinguish it from siblings without opening a schema.

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?

Explicit "When to use" (specialized task completed, instructions no longer needed in prompt context) and "When NOT to use" (do not delete from skills-vault/) sections are present. The exclusion effectively routes the agent away from permanent deletion, which is the main confusion risk for an uninstall tool.

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