Skip to main content
Glama

recategorize_artifact

Destructive

Move a miscategorized artifact into the correct category—decoration or reusable feature—so Kiln versions and releases it under the right artifact type.

Instructions

Move a miscategorized artifact into the right category — "actually, this is a decoration / a reusable part".

Needs Kiln Pro.

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": {
      "source_id": "<source_id>",
      "source_kind": "<source_kind>",
      "target_kind": "<target_kind>"
    },
    "name": "recategorize_artifact"
  }
}

Input Schema

NameRequiredDescriptionDefault
signNoWhen true, also cut and sign a v1 release on the new artifact. When signing is not available to the caller the move still happens and the response says so; ``signed`` reports which. Default: false.
notesNoOperator note carried onto the new artifact. Default: "".
new_idNoOptional id for the new artifact; features / presets self-mint a UUID when omitted.
new_nameNoDisplay name for the new artifact; defaults to the source design's name.
signed_byNoOptional signer identity; server-verified.
source_idYesThe artifact being moved.
source_kindYes``"design"`` (the only valid source in v1).
target_kindYes``"decoration"`` or ``"feature"``.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.5.1
    • addedInput schema / properties / new_id / description
      Added value: +"Optional id for the new artifact; features / presets self-mint a UUID when omitted."
    • addedInput schema / properties / new_name / description
      Added value: +"Display name for the new artifact; defaults to the source design's name."
    • changedInput schema / properties / notes / description
      Previous value: -"Default: \"\"."New value: +"Operator note carried onto the new artifact. Default: \"\"."
    • changedInput schema / properties / sign / description
      Previous value: -"Default: false."New value: +"When true, also cut and sign a v1 release on the new artifact.  When signing is not available to the caller the move still happens and the response says so; ``signed`` reports which. Default: false."
    • addedInput schema / properties / signed_by / description
      Added value: +"Optional signer identity; server-verified."
    • addedInput schema / properties / source_id / description
      Added value: +"The artifact being moved."
    • addedInput schema / properties / source_kind / description
      Added value: +"``\"design\"`` (the only valid source in v1)."
    • addedInput schema / properties / target_kind / description
      Added value: +"``\"decoration\"`` or ``\"feature\"``."
  2. Addedv1.5.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known; the description adds only the Kiln Pro prerequisite. It does not disclose the critical behavioral question for this tool — whether the source design is removed or retained after the move — nor the signing fallback behavior ('the move still happens and the response says so'), which is only visible in a parameter description.

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?

Two short sentences, front-loaded with the action, and no filler. The quotation-style phrasing is informal but still quick to parse; the fragment 'Needs Kiln Pro.' is terse yet informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With eight parameters fully documented and no output schema, the schema carries most of the burden, but the description omits the one thing an agent most needs for a destructive move: the fate of the source artifact and whether the operation can be undone. Adding that single sentence would make the definition complete.

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%, including the sign/signed_by fallback semantics and the new_id/new_name defaults, so the baseline of 3 applies. The description adds no parameter meaning beyond the schema; its examples loosely map to target_kind values but do not clarify kinds or constraints.

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?

States a concrete verb and resource: move an artifact from one category to another, with examples of the target categories (decoration, reusable part/feature). The intent is unambiguous and no sibling tool performs the same recategorization, though the name 'recategorize' vs the description's 'move' introduces slight wording drift.

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 scenario ('miscategorized artifact') implies when to use it, and 'Needs Kiln Pro' is a genuine gating prerequisite that saves a failed call. However, it never names an alternative path (e.g. creating a new decoration/feature and deleting the design) or states what happens when the move is not appropriate.

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

Deploy Server

Other Tools