Skip to main content
Glama

Copy template

copy_template

Duplicates a template, and everything in it, into a template of its own. This is how a template is copied -- not export_template followed by create_template, which is refused and was never the same thing: an Image, Video or read-only File in a document has no stored file behind it, so a copy built that way lost every one silently. Here the template is read on the server, so the copy gets every part of it. The copy has its own key and so does every task, field, parameter and rule in it, and each condition, due date anchor, task tag, parameter binding, Data Set control link, dynamic value binding (a field filled from another field, from a field of a Data Set record, or from a global value) and {{content.x}} token inside is repointed at the copy's own -- nothing in it reaches back into the original. Images, videos and read-only files are shared rather than duplicated, since both templates belong to one workspace. An archived template can be copied and the copy is live. A key acting as a member needs the Template.Creator permission and Edit on the library folder the template is in, which is what the app asks before its own Duplicate button will copy it; an administrator key and a workspace key may copy anything.

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": {
      "templateKey": "<templateKey>",
      "name": "<name>"
    },
    "name": "copy_template"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesWhat to call the copy. Required. It may be the same as the original's -- two templates are allowed to share a name and the key tells them apart -- but a name somebody can pick out of the library is worth more.
descriptionNoThe copy's description. Omit it to keep the original's; send an empty string to give the copy none.
templateKeyYesThe key of the template to copy, from list_templates. Required.
idempotencyKeyNoOptional. Send the same key again to retry this call safely: the retry gives back the first call's answer instead of doing the work twice. Use a new key whenever you mean a new operation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare destructiveHint=false, so the description carries the real burden and does it well: it explains deep-copy semantics, key remapping for tasks/fields/parameters/rules and bindings, that media is shared rather than duplicated within the workspace, and that the copy of an archived template is live. This is materially useful context an agent cannot get from the annotations.

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?

Purpose is front-loaded in the first sentence and nearly every clause adds a distinct behavior, but the prose is a dense run-on with long parentheticals (the dynamic value binding aside) that slows scanning. Efficient in content, less so in structure.

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?

No output schema exists, and the description covers the copy semantics, isolation from the original, media handling, archived-state behavior and permission requirements. An agent has everything needed to call it correctly and anticipate the result.

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 name, description, templateKey and idempotencyKey are already well documented in the schema. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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?

Opens with a specific verb and resource ('Duplicates a template, and everything in it, into a template of its own') and explicitly distinguishes itself from the export_template + create_template route. An agent can identify the operation and its scope immediately.

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?

States outright that this is the way to copy a template and that the export-then-create alternative is refused, giving the reason. It also specifies when it is permissible (archived templates can be copied; member keys need Template.Creator plus Edit on the library folder; admin/workspace keys unrestricted).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.