SHIP

Get project transfer

get_project_transfer

Read-onlyIdempotent

Read the transfer of a project's repository to the person's GitHub account: its state, what the person does next, where the repository goes, and when SHIP deletes its archived copy. This tool only reads: SHIP moves the transfer on by itself. 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.

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

Input Schema

Name	Required	Description	Default
`projectId`	Yes	Project id from list_projects

Output Schema

Name	Required	Description
`id`	Yes
`state`	Yes	`requested` before SHIP checks anything. `awaiting_target` while the founder must name their own empty repository. `mirroring` while SHIP copies every branch and tag into it, and `verifying` while SHIP checks that each one has the same commit. `repointed` when the project uses the founder's repository. `archived` when SHIP's own copy is read-only and waits for its delete, and `done` after the delete. `failed` gives the cause in `failure`. `cancelled` when the founder stopped it before the repoint.
`action`	Yes	What the founder does next: name their empty repository with SHIP's GitHub App installed on it, or wait while SHIP copies and checks it.
`choices`	Yes
`failure`	Yes
`version`	Yes
`checkedAt`	Yes
`createdAt`	Yes
`projectId`	Yes
`updatedAt`	Yes
`repository`	Yes
`completedAt`	Yes
`deleteAfter`	Yes
`pollAfterSeconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description reinforces this with 'This tool only reads: SHIP moves the transfer on by itself,' which tells the agent that state advances server-side without any write from the client. It also discloses the state-dependent next actions (choose_target vs wait) and the polling delay field pollAfterSeconds, going beyond the annotation set. It stops short of describing terminal/failure states or what the archived-copy deletion window looks like in practice.

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 definition is front-loaded with the purpose and the read-only guarantee before branching into the choose_target and wait cases. It is dense and every sentence carries information, though the long compound sentences with embedded call instructions are harder to scan than a short bulleted state breakdown would be.

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?

An output schema exists, so return shape need not be described, yet the description usefully explains how to act on the result, which is the key decision support for this tool. Combined with annotations covering safety, an agent has enough to call it correctly. The only missing piece is guidance for the no-transfer-yet or completed states.

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?

There is a single required parameter, projectId, and the schema already documents it at 100% coverage ('Project id from list_projects'). The description adds no further meaning about the parameter itself, so the baseline of 3 applies. The richest added semantics (pollAfterSeconds, next action) belong to the response rather than the input.

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 ('Read the transfer of a project's repository to the person's GitHub account') and enumerates exactly what the read returns: state, next person action, destination, and deletion timing. It is clearly distinguishable from the sibling mutators transfer_project_repository and cancel_project_transfer, and it explicitly names transfer_project_repository as the follow-up call for the choose_target case.

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?

Usage is spelled out per state: on choose_target, the agent should call transfer_project_repository with the connection's connectorId and owner/name; on wait, it should re-read get_project_transfer after pollAfterSeconds. The polling loop is thus explicit. It does not cover the negative case, e.g. what to do when no transfer exists yet or when the transfer has completed, which keeps it from a 5.

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

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