Skip to main content
Glama

MoveProject

Destructive

Moves a project to another workspace of the same person, as one operation (OperationKind MOVE): it is stopped here, backed up into the destination's backups, restored and started there under the same project_id, then deleted here. Each database it is linked to (Project.dependencies) stays here, with its other apps, if any, running on: there the project uses one of the same engine instead, one the destination has or a new one, with the data of the database it signs in to copied, or none (DatabaseSwitch). A database project moves only when no app is linked to it. workspace is the source. Waits as DeployProject does (wait_seconds), then GetOperation, in either workspace, which once it ended answers the same move_message and the project. Answers, once it ended, with the project as it is in the destination, and move_message: what changed (hosts move to the destination's apps_domain, a domain of the person's own must point at its hostname, a new SSH command, which database it uses there instead of each, and with what data) and what stayed behind (operation history, logs, incidents, uptime, earlier snapshots, and what each database it left still holds). Until the restore succeeded, a failure undoes it: the source's services run again as they did, unless its failure says they did not start again; the move's snapshot stays in the destination's backups, as a deleted project's. After that it only goes forward: one that FAILED then moved the project, and its failure names what the source still holds. While it runs, a change to the project is UNAVAILABLE + ProjectBusy (kind MOVE) in either workspace, and so is a read where it is not then (before its restore, after its deletion from the source); afterwards, a call for it to the source is FAILED_PRECONDITION + ProjectMoved, until the source has a project of that id again. While it runs, a change to a database it leaves here, or to the one it uses instead there, is ProjectBusy too, as is a read of a new one before the move made it; GetOperation answers the move with any of their project_ids. INVALID_ARGUMENT = switch_databases names a database the project is not linked to, or twice, an env_prefix where the machine wrote the lines, none where it did not, one of no form a link takes or one two switches share, or an into the destination lacks or of another engine, or one two switches share, copies of more than 32 databases, or to_workspace is the source or none of the caller's; PERMISSION_DENIED + WorkspaceNotGranted = one this token may not reach. ALREADY_EXISTS = the destination has a project of the project's id, or of the id a new database takes, or operation_id is an operation of the project's or another move's already. FAILED_PRECONDITION = a database project with apps linked to it (the message names them: move each, or unlink it), a machine needs an update first (the message names it), the project has no deploy yet, or the destination's backups are off (its Machine.backups_enabled), which a move goes through.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "MoveProject"
  }
}

Input Schema

NameRequiredDescriptionDefault
workspaceNoThe workspace: its id or name (ListWorkspaces). Omit when the account has one.
project_idNo
operation_idNoAs DeployProject's operation_id: the move's.
to_workspaceNoThe destination, as `workspace` takes one: its id or name.
wait_secondsNoAs DeployProject's wait_seconds.
switch_databasesNoWhat it uses in to_workspace instead of each database it is linked to (Project.dependencies), which stays here. One left out: the destination's database of its id and engine, if it has one, else a new one, with the data of its copy_database.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

The description goes far beyond the annotations by explaining exactly what is destroyed, what is copied, what stays behind, rollback behavior before restore, busy-state behavior during the move, and post-move source-workspace behavior. This is exactly the kind of destructive-operation context the annotations alone cannot provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The purpose is front-loaded, but the body is an extremely long, dense, run-on block that is difficult to parse. Many details are valuable, yet the description is not appropriately sized or structured for quick agent consumption, and several clauses could be organized more cleanly.

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 a cross-workspace destructive move, the description is remarkably complete: it covers return values, rollback boundaries, busy states, error conditions, and database-switch semantics. No output schema exists, but the description explains what the operation answers with, so the missing output schema is not a gap.

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 coverage is already high at 83%, so the baseline is 3, but the description adds useful meaning: it clarifies that `workspace` is the source, `to_workspace` is the destination, and `switch_databases` controls what the project uses in the destination instead of each source-linked database. It also explains the default behavior for omitted switch entries.

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: 'Moves a project to another workspace of the same person, as one operation (OperationKind MOVE).' It clearly distinguishes the operation from a deploy by describing the stop/backup/restore/start/delete sequence and by referencing DeployProject only for wait semantics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The use case is strongly implied by the opening sentence, but there is no explicit when-to-use or when-not-to-use guidance relative to siblings such as CreateTransfer or DeployProject. An agent can infer that this tool is for moving a project between workspaces, but it must infer that from purpose rather than from explicit routing guidance.

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