Skip to main content
Glama
Sign In

SHIP

by ai.letsship
OverviewDiscussionsAdmin

Transfer project repository

transfer_project_repository
DestructiveIdempotent

Move the repository that SHIP made for a project with Start from scratch into the person's own empty GitHub repository, or name that repository for a transfer that waits on it. Only the repository moves. The hosted site, its waitlist, its database and SHIP's models, paid in credits, stay. SHIP archives its own copy and deletes it after a grace period. Only an owner of the workspace can do this, and never while missions or site publishes of the project run. The result gives the next step in action: choose_target means the person makes an empty repository on their own GitHub account, installs SHIP's GitHub App on it, and you call transfer_project_repository again with that connection's connectorId and the repository as owner/name. wait means SHIP copies and checks the repository: read the transfer with get_project_transfer after pollAfterSeconds. After the project uses the new repository, the transfer cannot be cancelled.

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": "transfer_project_repository"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectIdYesProject id from list_projects
repositoryNoThe person's empty repository as owner/name, which that installation covers
connectorIdNoThe workspace's GitHub connection for the person's own installation of SHIP's GitHub App
idempotencyKeyNoA key of your own: a repeat with the same key answers the same transfer

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds substantial context the agent could not infer: SHIP archives its own copy and deletes it after a grace period, everything except the repository stays behind, and the transfer cannot be cancelled once the project uses the new repository. It does not state the length of the grace period or whether the deletion is recoverable, which keeps it just short of a 5.

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?

Everything is packed into one dense paragraph, but it is front-loaded with the core action and scope boundary before the operational details. The next-step branches (choose_target / wait) would be easier to scan as a list, and a sentence or two could be tightened, but no sentence is filler.

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?

There is no output schema, and the description compensates by describing the shape of the result through its action values and the follow-up each requires. Combined with the permission and concurrency constraints, an agent has enough to invoke this destructive, multi-step operation correctly.

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 100%, so the baseline is 3, but the description goes beyond the schema by explaining the conditional role of two optional parameters: connectorId and repository (as owner/name) are supplied on the second call after choose_target creates an empty repo and the GitHub App is installed. projectId and idempotencyKey get nothing beyond their schema text.

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 states a specific verb and resource ('Move the repository that SHIP made for a project with Start from scratch into the person's own empty GitHub repository') and immediately delimits scope: 'Only the repository moves. The hosted site, its waitlist, its database and SHIP's models... stay.' That precision separates it from get_project_transfer and cancel_project_transfer without opening any 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 names prerequisites and exclusions explicitly: 'Only an owner of the workspace can do this, and never while missions or site publishes of the project run.' It also routes the agent through both outcome branches, telling it to call this tool again when the result is choose_target and to read get_project_transfer after pollAfterSeconds when the result is wait.

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

All SHIP 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