Skip to main content
Glama

Anima MCP Server

by io.github.AnimaApp
OverviewDiscussionsAdmin

Duplicate Artifact

artifact-duplicate

Duplicate (clone) an EXISTING artifact into a new, independent artifact.

This copies the artifact's code, assets, and supported database content. If a supported database cannot be copied, the entire duplication fails and no usable copy is returned. It does NOT copy chat or custom domains. This is different from running git clone locally: git clone only creates a local checkout, while this tool creates a new artifact with a new sessionId.

Requires sessionId for a readable source artifact that belongs to the caller's current team. Public, shared, or otherwise readable artifacts in other teams cannot be duplicated with this MCP v1 tool. You need write in the workspace the copy goes to. name is optional; the default is " (Copy)".

Retry safety: duplication is not idempotent. If a call times out or its response is lost, list recent artifacts (workspace-list_artifacts) before retrying because the first call may already have created the copy.

Returns: { success, sessionId, sourceSessionId, name, artifactType, artifactUrl, nextSteps } — plus playgroundUrl and previewUrl when the copy is an app or knowledge artifact; a markdown copy gets previewUrl only

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional display name for the duplicated artifact.
sessionIdYesThe session id of a readable source artifact that belongs to the caller's current team.
workspaceIdNoWhere to create it — an id from workspace-list_workspaces. Optional when you can create in only one workspace; otherwise required, since there is no default workspace.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / workspaceId
      Added value: +{
+  "description": "Where to create it — an id from workspace-list_workspaces. Optional when you can create in only one workspace; otherwise required, since there is no default workspace.",
+  "type": "string"
+}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations, it discloses non-idempotency, retry behavior (list artifacts before retrying), atomic failure when a database cannot be copied, and what is not copied (chat, custom domains). This is substantial behavioral context that annotations alone could not convey.

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 longer than average but every sentence carries operational information, and it is front-loaded with the primary purpose before requirements and return shape. It could be tightened slightly, but the structure (purpose, exclusions, requirements, retry safety, returns) is logical.

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?

With no output schema, the description compensates by enumerating the exact return fields and their conditional presence (playgroundUrl/previewUrl). It covers failure semantics, permissions, retry behavior, and destination selection—enough for an agent to invoke it correctly without external 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 parameter descriptions already cover all three parameters (100% coverage), so the baseline is 3. The description adds real value by specifying the default name ('<source name> (Copy)') and clarifying when workspaceId is optional vs required—information absent from the schema.

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 plus resource: 'Duplicate (clone) an EXISTING artifact into a new, independent artifact.' It states the key scope (copies code, assets, supported database content; does not copy chat/custom domains) and clearly separates this from artifact-create/delete/edit by emphasizing it acts on an existing artifact.

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?

It gives concrete conditions for use: source must be readable and in the caller's current team, caller needs write access to the destination workspace, and it explicitly contrasts itself with local git clone. It does not explicitly name a sibling like artifact-create as the alternative for creating from scratch, so it stops just short of an explicit when-to-use vs alternative routing.

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

All Anima MCP Server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources