Skip to main content
Glama

transfer_artifact_between_orgs

Destructive

Move a design, preset, or feature from one organization's ownership to another. Specify source and destination orgs to transfer the artifact; requires Kiln Business.

Instructions

Move an artifact from one org's ownership to another.

Needs Kiln Business.

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": {
      "artifact_type": "<artifact_type>",
      "artifact_id": "<artifact_id>",
      "from_org_id": "<from_org_id>",
      "to_org_id": "<to_org_id>"
    },
    "name": "transfer_artifact_between_orgs"
  }
}

Input Schema

NameRequiredDescriptionDefault
to_org_idYesThe org that will own the artifact. When it already does, nothing changes and the answer says ``already_transferred``.
artifact_idYesThe id of the artifact moved.
from_org_idYesThe org that owns the artifact now. When a different org owns it, the transfer is refused.
artifact_typeYesThe kind of artifact moved: ``"design"``, ``"preset"`` or ``"feature"``; the move to the new org refuses any other kind.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • addedInput schema / properties / artifact_id / description
      Added value: +"The id of the artifact moved."
    • addedInput schema / properties / artifact_type / description
      Added value: +"The kind of artifact moved: ``\"design\"``, ``\"preset\"`` or ``\"feature\"``; the move to the new org refuses any other kind."
    • addedInput schema / properties / from_org_id / description
      Added value: +"The org that owns the artifact now.  When a different org owns it, the transfer is refused."
    • addedInput schema / properties / to_org_id / description
      Added value: +"The org that will own the artifact.  When it already does, nothing changes and the answer says ``already_transferred``."
  2. Addedv1.5.0

TDQS

A3.7/5.0
Behavior3/5

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

The annotations already establish that this is a destructive, non-read-only operation, while the description adds that ownership—not artifact content—is what changes and that a Kiln Business plan is required. It does not further explain permission requirements, effects on either org's access, reversibility, or other operational consequences.

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?

The action is front-loaded in one direct sentence, followed by a separate, useful subscription prerequisite. There is no filler or redundant wording.

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?

Together with the complete schema and safety annotations, the description is sufficient for a basic correct invocation. However, for a destructive ownership mutation with no output schema, it remains thin on authorization, access consequences, and success/error response behavior beyond the fragments embedded in parameter descriptions.

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 description coverage is 100%, including the allowed artifact types, current-owner validation, refusal behavior, and the idempotent already_transferred case. The description adds no parameter-level detail beyond that schema, so the high-coverage baseline of 3 applies.

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?

“Move an artifact from one org's ownership to another” gives a specific action, resource, and ownership scope. It does not distinguish the operation from related siblings such as backfill_artifact_into_org or identify the supported artifact kinds in the description itself.

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?

The ownership-transfer context and the explicit “Needs Kiln Business” prerequisite help an agent decide whether the tool is applicable. There is no when-not guidance or alternative for related artifact/org operations, but the core use case and plan requirement are clear.

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