Skip to main content
Glama
Sign In

OrgGen AI

by ai.orggen
OverviewDiscussionsAdmin

fork_linked_project

Destructive

FORKS a linked project: makes an INDEPENDENT COPY of it that you own, then repoints the host block to that copy. It is the escape hatch when a linked project stays READ-ONLY — access bounded to a shared block (cell_grant), write lock set on the target, PINNED version, or a role that does not write on the target — and you want to be able to modify it without depending on those conditions (a role that writes, on a NON-bounded and NON-locked link, already opens inline editing — see link_project_to_cell). READ access to the target is enough to fork. The copy is a detached SNAPSHOT: it will no longer follow any change to the original, and the original is never modified. If the link was PINNED to a version, THAT version is copied. The new project counts toward your project cap, and writing into it requires TARGETING it — over MCP, expectedProjectId on each write or set_active_project; in the in-app chat neither exists: nothing is written there this turn, the interface (or focus_view dive, run at turn end) dives in, and the writing happens on the NEXT turn. What is NOT copied: tasks, comments, documents and attachments, the version history, shares, project metadata (agent checkpoints, set_project_metadata), pending access requests, block identifier aliases (a renamed former identifier will no longer resolve in the copy — only canonical identifiers are carried over), the chat conversation history, as well as the plans in progress, reviewable proposals and meeting suggestions attached to it. Linking a project WITHOUT copying it (it stays live and shared) is the job of link_project_to_cell; starting an EMPTY sub-view is the job of create_nested_project.

Input Schema

NameRequiredDescriptionDefault
nameNoName of the created project. Omitted, it takes the label of the link followed by " (copy)".
cellIdYesID of the block of THIS project that carries the link to fork. The fork copies the project targeted by this link, then REPOINTS this same block to the copy.
expectedProjectIdNoUUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / cellId / description
      Previous value: -"ID du bloc de CE projet qui porte le rattachement à forker. Le fork copie le projet visé par ce rattachement, puis REPOINTE ce même bloc vers la copie."New value: +"ID of the block of THIS project that carries the link to fork. The fork copies the project targeted by this link, then REPOINTS this same block to the copy."
    • changedInput schema / properties / expectedProjectId / description
      Previous value: -"UUID du projet visé par CET appel. Cible RÉELLEMENT ce projet au lieu du projet de session. Refusé sans rien modifier si l'accès n'est pas accordé."New value: +"UUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted."
    • changedInput schema / properties / name / description
      Previous value: -"Nom du projet créé. Omis, il reprend le libellé du rattachement suivi de « (copie) »."New value: +"Name of the created project. Omitted, it takes the label of the link followed by \" (copy)\"."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The annotations already signal a destructive, non-read-only operation, and the description adds substantial context beyond them: the copy is a detached snapshot, the original is never modified, the pinned version is copied, the new project counts toward the project cap, and writes require targeting via expectedProjectId or set_active_project. It also lists exactly what is not copied and explains the in-app chat turn boundary. These details materially affect how an agent should plan and follow up.

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 core operation is front-loaded in the first sentence, and the rest is organized around usage conditions, snapshot behavior, targeting, and exclusions. It is long and dense, with some parenthetical caveats, but the length is largely justified by the tool's complexity. It is not wasteful, though it could be slightly tighter.

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?

Given the complexity of forking a linked project, the description covers the important behavioral edges: what is copied, what is not copied, how pinning affects the copy, how the block is repointed, and how subsequent writes must target the new project. Annotations cover the safety profile, and no output schema exists; the description does not need to explain return values. It is complete enough for correct invocation and follow-up.

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%, and the schema already explains cellId, name defaulting, and expectedProjectId targeting. The description reinforces the host-block repointing and project targeting context but does not add parameter-specific syntax or constraints beyond what the schema already provides. A baseline 3 is appropriate when the schema carries the 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 opens with a specific verb and resource: FORKS a linked project into an independent copy and repoints the host block. It also distinguishes this from sibling operations by naming link_project_to_cell and create_nested_project. An agent can tell exactly what this tool does without opening the schema.

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?

It explicitly frames the tool as an escape hatch for a linked project that stays READ-ONLY due to bounded access, a write lock, a pinned version, or an insufficient role. It names alternatives: use link_project_to_cell when linking without copying, and create_nested_project for an empty sub-view. This leaves little ambiguity about when to choose this tool.

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

All OrgGen AI 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