Skip to main content
Glama

Restore library asset

restore_asset
Idempotent

Restore a deleted library asset by its ID to bring it back from the deleted list; restoring a non-deleted asset changes nothing and it won't become default.

Instructions

Bring one of your deleted library items back (the id from delete_asset or list_deleted); restoring an item that is not deleted changes nothing. It does not become a default again. Returns { ok }.

Input Schema

NameRequiredDescriptionDefault
assetIdYesLibrary asset id (from delete_asset)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.26.3
    • changedInput schema / properties / assetId / description
      Previous value: -"Library asset id (from remove_asset)"New value: +"Library asset id (from delete_asset)"
  2. Addedv0.19.1

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the idempotentHint annotation, it discloses two non-obvious behaviors: the call is a silent no-op on non-deleted items, and the restored asset does not regain default status. It also documents the return shape ({ ok }) despite no output schema. Not covered: permissions/auth requirements or whether the restore window is limited.

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 compact sentences, action and source of the id front-loaded, with the edge case and return value in a trailing clause. No filler or restatement of the tool name.

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 single-parameter mutation with no output schema, the description covers invocation, the id source, the no-op case, and the response shape. Missing only peripheral context such as whether a purged asset can ever be restored, which matters given purge_asset exists nearby.

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 a source the schema omits: the schema says only 'from delete_asset', while the description also points to list_deleted as a way to obtain the assetId.

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 (restore) on a specific resource (deleted library item/asset), and the resource name distinguishes it from restore_project and restore_clip in the sibling list. An agent can identify the correct tool 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 Guidelines4/5

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

Explicitly says the id comes from delete_asset or list_deleted, which tells the agent both the precondition and the prerequisite call sequence. It also covers the no-op case (restoring a non-deleted item changes nothing), though it never names explicit alternatives such as restore_project/restore_clip for other resource types.

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