Skip to main content
Glama

Remix an R3 project

r3_project_remix

Remix a project: copy the published release of a project into a NEW private project in this account. The source is a Community or live project whose author allowed remixes (for now R3's own starters and showcase projects), or one of the account's own. The files it uses are copied into the account's own lists, the new project carries a credit line naming the original and its author, and its code starts held until Run is pressed in the R3 editor. The original is not changed.

Limits: 20 remixes per account in 24 hours and 5 per agent key in an hour; one remix copies at most 50.0MB of files; a project with videos cannot be remixed yet.

Returns the new project id, which every other project tool takes, the credit, and notes on anything that could not be copied. r3_editor_open opens it in the user's R3 tab and r3_preview_create makes a private link to show it.

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": {
      "projectId": "<projectId>"
    },
    "name": "r3_project_remix"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoThe new project's name. Defaults to "<original name> (remix)", made unique in this account. Max 120 characters.
projectIdYesThe project to remix: its id from its R3 page, r3_project_list, or the user.

Output Schema

NameRequiredDescriptionDefault
nameYes
notesYes
answerYesThis answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.
creditYes
projectIdYes
copiedBytesYes
environmentYes
sourceProjectIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / notes / items / properties / count
      Added value: +{
      +  "type": "number"
      +}
    • changedOutput schema / properties / notes / items / required
      Previous value: -[
      -  "code",
      -  "text"
      -]New value: +[
      +  "code",
      +  "count",
      +  "text"
      +]
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (non-read-only, non-destructive, non-idempotent, open-world), the description adds substantial context: rate limits (20/account/24h, 5/agent key/hour), a 50MB copy ceiling, an exclusion for projects with videos, the fact that code starts held until Run, an added credit line, and that the original is untouched. These are exactly the behavioral traits annotations cannot 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?

Front-loaded with the core action, then constraints, then return value and next steps — a logical order. It is on the long side and the credit-line/detail sentence is packed, but nearly every clause carries actionable information (limits, exclusions, allowed sources).

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?

For a mutating, quota-limited, cross-project copy operation this covers source eligibility, limits, exclusions, side effects (credit line, held code), what is returned, and which tools to call next. An output schema exists, so the brief return summary is sufficient rather than redundant.

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%, so both projectId and name are already documented, including the default naming pattern and the 120-character cap. The description adds only indirect meaning by noting the returned project id is 'what every other project tool takes', which gives context for projectId's format rather than new parameter semantics.

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 leads with a specific verb+resource ('Remix a project') and immediately defines the mechanics: copying the published release of a source project into a NEW private project in this account. It distinguishes the operation from plain creation by specifying the source must be a remix-enabled Community/live project or one of the account's own, and by noting the original is unchanged.

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?

Eligibility to use it is spelled out clearly (remix-permitted public projects, R3 starters/showcase, or the account's own), along with hard limits and follow-up tools (r3_editor_open, r3_preview_create). It never explicitly routes the agent to r3_project_create for a from-scratch project, so the sibling-selection story is implied rather than stated.

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.

Resources