3DLogo.io

Duplicate a project

duplicate_project

Use when the user wants a variant without touching the original ("a gold version of this one"): copies a saved logo or coin project with its artwork, optionally under a new title; restyle the copy with update_project. Counts against the project cap. Does not spend credits.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`title`	No

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`url`	Yes	Opens the project in its studio
`kind`	Yes
`title`	Yes
`isPublic`	Yes
`modelUrl`	Yes	Public GLB, for published meshes
`shareUrl`	Yes	Public page, when published
`inputType`	Yes
`kindLabel`	Yes
`updatedAt`	Yes	ISO 8601
`thumbnailUrl`	Yes	Saved thumbnail; needs the owner's browser session

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedSep 6, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / properties / inputType / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / inputType / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / updatedAt / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / updatedAt / type
```
Added value: +[
+  "string",
+  "null"
+]
```

First observedSep 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already show readOnlyHint=false and destructiveHint=false, so the description correctly implies a mutating but non-destructive operation. The description adds valuable behavioral context beyond annotations: copying preserves the original, optionally under a new title, counts against the project cap, and does not spend credits. It doesn't mention whether an existing project with the same title is allowed, but overall it meaningfully supplements 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences with zero filler. The use-case trigger is front-loaded in quotes, then the action, then the alternative, then two side-effect constraints. Every clause earns its place.

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?

The tool has an output schema, so return values need not be described. With only 2 params and no enums, the description covers the main behavior and side effects. The only minor gap is explicitly saying 'id' must be the existing project to copy, though the phrase 'copies a saved... project' strongly implies it. Overall sufficient for correct invocation.

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 0%, so the description carries the burden for parameter meaning. The description explicitly mentions 'optionally under a new title', which maps to the 'title' param, and 'copies a saved project' implies the 'id' param. However, it doesn't clarify that 'id' is the source project ID, nor does it specify title behavior (e.g., what happens if omitted, uniqueness). It partially compensates but leaves room for ambiguity.

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 uses specific verb 'duplicate' plus resource 'saved logo or coin project with its artwork' and explicitly distinguishes the use case ('a gold version of this one') from creating or editing. It references update_project for restyling, making it clear this tool creates a copy rather than modifying the original. The title and description align with the tool name, and it stands apart from siblings like create_*_project, delete_project, and update_project.

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?

The opening phrase 'Use when the user wants a variant without touching the original' gives an explicit triggering condition. It names the alternative 'update_project' for restyling the copy, and it clarifies the two key side effects: counts against the project cap and does not spend credits. This is exemplary routing guidance.

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

All 3DLogo.io tools Inspect

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

Need Help?