# SHIP (remote · mcp.letsship.ai)

Assign Linear, Jira or GitHub issues to an AI coding agent team that plans, builds, reviews, tests.

- Trust score: 80/100 (high trust)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-17

## Components

- remote · `mcp.letsship.ai`: 80/100 (this document), [markdown](https://verifymcp.io/servers/ai-letsship-ship/mcp.md), [page](https://verifymcp.io/servers/ai-letsship-ship/mcp)

## Channel facts

- Endpoint: `https://mcp.letsship.ai/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `0.24.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-17.

- **Endpoint Security**: 92/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
  - The authorisation server supports Client ID Metadata Documents, the current MCP client-registration mechanism.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 71/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 9851 tokens (~136/item across 72 items; 72 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 17/100
  - Stability observed for 5 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (14% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 8 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 73 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the SHIP MCP server?

SHIP is a hosted endpoint at https://mcp.letsship.ai/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http ai-letsship-ship 'https://mcp.letsship.ai/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "ai-letsship-ship": {
      "url": "https://mcp.letsship.ai/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "ai-letsship-ship": {
      "type": "http",
      "url": "https://mcp.letsship.ai/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.ai-letsship-ship]
url = "https://mcp.letsship.ai/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ai-letsship-ship": {
      "type": "remote",
      "url": "https://mcp.letsship.ai/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add ai-letsship-ship --url 'https://mcp.letsship.ai/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  ai-letsship-ship:
    url: "https://mcp.letsship.ai/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "ai-letsship-ship": {
      "Transport": "http",
      "Url": "https://mcp.letsship.ai/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add ai-letsship-ship -t streamable-http -u 'https://mcp.letsship.ai/mcp'
```

### Other

```json
{
  "mcpServers": {
    "ai-letsship-ship": {
      "type": "http",
      "url": "https://mcp.letsship.ai/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-17 (score 80, +1)

- [functional] Server version: 0.25.0 → 0.26.0
- [functional] New tool “mark_setup_step”

### 2026-10-16 (score 79, 0)

- [functional] Server version: 0.24.4 → 0.25.0

### 2026-10-14 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-13 (score 78, 0)

- [security] Tool “set_mission_disposition” is now declared destructive
- [functional improvement] Stability: unverified → 0.03
- [functional] Server version: 0.24.2 → 0.24.4
- [cosmetic] “bind_mcp_server” reworded the description of “transport”
- [cosmetic] “save_sandbox_registry” reworded the description of “scheme”
- [cosmetic] “save_sandbox_template” reworded the description of “dockerfile”
- [cosmetic] “set_agents_override” reworded the description of “effort”
- [cosmetic] “set_agents_override” reworded the description of “harness”
- [cosmetic] “set_agents_override” reworded the description of “model”
- [cosmetic] “update_scheduled_task” reworded the description of “name”
- [cosmetic] “update_scheduled_task” reworded the description of “skipIfPreviousOpen”

### 2026-10-12 (score 78)

First indexed and scored.

## MCP tools (72)

### `healthz` (~19 tokens)

API health probe

Returns the upstream API status, environment, and version.

### `whoami` (~52 tokens)

Identify the calling principal

Returns the caller's identity, org, role, role-derived RBAC capabilities, and token scopes. Use this to check whether the current token may perform an action (e.g. config:write) before attempting it.

Output parameters:

- `capabilities` (array)
- `orgId` (string|null)
- `principalType` (string): agent: a self-registered agent nobody has claimed yet. It has no user, org, role or scopes, and reaches only /me and /scopes until a person claims it.
- `projectId` (string|null): The project this credential is bound to, or null when it is org-wide. A bound token can read and act only on that project, and on nothing org-wide - so a caller can see the boundary it works within r…
- `role` (string|null)
- `scopes` (array)
- `userId` (string|null)

### `get_setup_progress` (~125 tokens)

Get setup progress

Read what the workspace has set up with SHIP so far, as the console's setup checklist shows it: up to 13 milestones in three groups, taken in order (get started, make it yours, make it autonomous). `activeGroup` names the group to work on now, and each group carries its own count. Each milestone says whether it is reached and, when a console page takes it and the caller's role can, the page that does it. `next` names the first milestone not reached yet. Use it to suggest the next step to a person.

Output parameters:

- `activeGroup` (string|null)
- `activeGroupProgress` (object|null)
- `complete` (boolean)
- `firstMission` (object|null)
- `groups` (array)
- `guides` (array)
- `next` (string|null)
- `orgId` (string)
- `reachedCount` (integer)
- `totalCount` (integer)

### `get_billing` (~49 tokens)

Get workspace credits

Read the workspace's credit balance by source and expiry, whether a new mission would start now, the per-mission credit ceiling, the project allowance and recent usage. Check it before dispatching work.

### `list_billing_ledger` (~108 tokens)

List workspace credit ledger

List where the workspace's credits went, newest first: one entry per mission (its start, each further 3 agent-hours, and messages charged before messages became free), per grant, per adjustment and per expiry. Pass nextCursor back as cursor for the next page. Owners and admins only.

Input parameters:

- `cursor` (string): nextCursor from the previous page; omit for the newest entries.
- `limit` (integer): Entries per page, 1-100 (default 50).

### `list_credit_offers` (~152 tokens)

List credit packs, the monthly plans and Enterprise

List what SHIP sells: the credit packs (credits, the tax-inclusive price in US dollars and the price per credit), the monthly plans under `team.plans` (Starter and Scale: each its credits a month, monthly price, price per credit, which credits added on top also cost, and agents at once), the range of credits a workspace on a plan can add at once, Enterprise under `enterprise` (the minimum yearly credit commitment, the highest and lowest price per credit, and the agents at once at the minimum; contracts are sold by SHIP, not through checkout), what Free and the packs allow (`limits`), plus the trial size. The same catalog the pricing page shows.

### `start_credit_checkout` (~322 tokens)

Start buying credits or a monthly plan

Opens a payment page and returns its URL. Nothing is charged until the buyer pays on that page. It sells one credit pack, a monthly plan (offer team, with teamPlan starter or scale, a subscription that renews until cancelled), or extra credits for a workspace already on a plan (offer team_credits, for quantity credits at that plan's own price per credit, paid once, expiring with the plan month). Only a workspace on a plan can use team_credits. Only owners and admins can open a page. The server refuses the request while startNow is false, and the same idempotencyKey returns the same page.

Input parameters:

- `idempotencyKey` (string): Reuse on retry to get the same page back.
- `offer` (string, required): A pack, team or team_credits, from list_credit_offers.
- `quantity` (integer): Credits for team_credits, within the range list_credit_offers gives; omit for a pack or a plan.
- `startNow` (boolean, required): Records the buyer's own consent to start the credits at once, during the withdrawal period, against this text: "Start my credits now, so they can be used during the 14-day withdrawal period. If I wit…
- `teamPlan` (string): The plan to start, for offer team only: starter or scale, from list_credit_offers.

### `update_team_subscription` (~147 tokens)

Change the monthly plan subscription

Change the workspace's monthly plan subscription: plan switches between starter and scale from the next renewal on (nothing is charged or refunded for the current month; passing the current plan drops a waiting switch), or cancelAtPeriodEnd true ends it when the month already paid for ends, false resumes it before then. Pass at least one. Owners and admins only. The answer is the subscription as it now stands, with any waiting switch under nextPlan.

Input parameters:

- `cancelAtPeriodEnd` (boolean): true ends the subscription at the end of the paid month; false resumes it.
- `plan` (string): The plan from the next renewal on: starter or scale, from list_credit_offers.

### `request_more_credits` (~75 tokens)

Ask for more credits

Ask for more credits for the workspace, saying what they are for. Any member may ask. The answer says who has the request: SHIP for a sponsored or Enterprise workspace, its owners and admins otherwise. A message sent while a request is open joins it.

Input parameters:

- `message` (string, required): What the credits are for.

### `get_notices` (~90 tokens)

Get workspace notices

Read what needs attention in the workspace, critical first: a tracker connection its vendor no longer accepts (missions cannot start or report back until someone reconnects it), or credits running out. Each notice has a stable id and kind, a message and, when the caller can act, an action URL to hand to a person. A notice the caller dismissed is left out. Check it before dispatching work.

### `dismiss_notice` (~103 tokens)

Dismiss a workspace notice

Close a notice for the person this token acts for, as the console's close button does. Only a notice with dismissible: true can be closed (a low balance). It stays closed while its id lasts: a low balance that a top-up ends and a later spend brings back has a new id and shows again. Critical notices cannot be closed.

Input parameters:

- `noticeId` (string, required): The notice's id from get_notices, e.g. credits_low:<grant>

### `mark_setup_step` (~162 tokens)

Mark a setup step

Mark a step of the setup checklist completed or skipped for the person this token acts for, as the console's Mark as complete and Skip controls do; open removes the mark. Give step for one milestone, or group to mark every open step of that group (the console's Skip all). A marked step counts as done on that person's checklist and its status says how; reached stays false until SHIP sees the step done. Returns the checklist as it now stands. A token that acts for no person is refused.

Input parameters:

- `group` (string): A group id: marks every open step of the group.
- `mark` (string, required): open removes the caller's mark.
- `step` (string): The milestone id from get_setup_progress. Give step or group.

### `list_projects` (~59 tokens)

List projects

List the projects accessible to the calling principal. Returns id, slug, name, status, createdAt for each.

Input parameters:

- `cursor` (string): Opaque pagination cursor from a previous call
- `limit` (integer): Max results (default 20)

Output parameters:

- `data` (array)
- `nextCursor` (string|null)

### `get_project` (~40 tokens)

Get project

Fetch a single project by its UUID. Returns 404 if the project is not in the caller's org.

Input parameters:

- `projectId` (string, required): Project UUID

Output parameters:

- `autoMerge` (boolean)
- `createdAt` (integer)
- `defaultSandboxTemplateId` (string|null)
- `id` (string)
- `issueCode` (string|null)
- `llmConnectorId` (string)
- `missingConnectorKinds` (array)
- `name` (string)
- `orgId` (string)
- `scmConnectorId` (string)
- `scmOwner` (string)
- `scmRepo` (string)
- `slug` (string)
- `status` (string)
- `tracker` (string)
- `trackerConnectorId` (string|null)
- `trackerProjectId` (string|null)
- `trackerTeamId` (string|null)

### `update_project` (~279 tokens)

Change a project's settings

Change the settings of one project; a field you leave out keeps its value. status paused or archived stops new missions in the project, and active starts them again. autoMerge sets whether SHIP merges a ready pull request by itself. defaultSandboxTemplateId sets the sandbox the agents start in (null for the platform base). repoFullName and linearTeamKey connect the project to another repository or Linear team through the organization's existing connections. Change only what a person asked for. Answers the project as it now stands. Requires the projects:admin scope and the config:write capability.

Input parameters:

- `autoMerge` (boolean): true merges a ready pull request without a person
- `defaultSandboxTemplateId`: A sandbox id (sbt_...) from list_sandbox_templates, or null for the platform base
- `issueCode` (string): A GitHub Issues project's issue id prefix, 2-5 characters; only new ids use it
- `linearTeamKey` (string): The key of the Linear team to connect, e.g. ENG
- `name` (string): A new name
- `projectId` (string, required): Project id, from list_projects
- `repoFullName` (string): owner/repo of the repository to connect, through the organization's GitHub connection
- `status` (string): active, paused or archived

### `start_mission` (~219 tokens)

Start a mission

Hand a mission off to the AI agent team. Omit startAt for the default full run (planner first); pass startAt='builder' with a plan to skip straight to coding; pass startAt='reviewer' or startAt='qa' with an existing prNumber to hand off an existing build. Requires the missions:run token scope.

Input parameters:

- `agents` (object): Per-role harness/model override for THIS mission only; overrides ship.yml without changing it
- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-244 or WEB-42
- `plan` (string): Hand-off plan markdown, for startAt='builder'
- `prNumber` (integer): Existing open PR number, required for startAt='reviewer' or startAt='qa'
- `projectId` (string, required): Project id the mission belongs to
- `startAt` (string): Pipeline stage to enter at; omit for the default full run starting at the planner

### `create_mission` (~284 tokens)

Create a mission

Create the tracker issue AND start the run in one call, for work that has no issue yet. Pass entryStartAt='builder' with an entryPlan to hand over a plan you already wrote; pass entryStartAt='reviewer'/'qa' with entryPrNumber to hand over an existing build — in which case title may be omitted and the pull request's own title names the mission. This tool calls the SHIP API, documented at https://letsship.ai/docs/api. Requires the missions:run token scope.

Input parameters:

- `agents` (object): Per-role harness/model override for THIS mission only; overrides ship.yml without changing it
- `description` (string): Issue body; acceptance criteria written here are parsed as they would be on any issue
- `entryPlan` (string): Hand-off plan markdown, for entryStartAt='builder'
- `entryPrNumber` (integer): Existing open PR number, required for entryStartAt='reviewer' or 'qa'
- `entryStartAt` (string): Pipeline stage to enter at; omit for the default full run starting at the planner
- `labels` (array): Tracker labels to apply
- `projectId` (string, required): Project id the mission belongs to
- `title` (string): Issue title. Omit ONLY with entryPrNumber — the pull request's own title is then used

### `set_agents_override` (~624 tokens)

Set a per-issue agents-override for one role

Patch one role's harness/model/effort/prompt for a single mission, layered over ship.yml per-field (a role or field this call omits keeps resolving from ship.yml — SHIP-337). Use promptContent or promptPath(+promptRef) to run an ephemeral prompt experiment (spec D9) without committing to the target repo. Read-modify-write: this call is merged onto the previously stored override record (via get_agents_override), so a prior set for a DIFFERENT role — or a different field on this same role, e.g. an earlier harness pin — survives; the underlying PUT is a full-record replace and would otherwise silently drop it. This tool calls the SHIP API, documented at https://letsship.ai/docs/api.

Input parameters:

- `baseBranch` (string): Override the pipeline's fork/target branch for this mission
- `checkpoint` (boolean): Pause the pipeline after this role's stage completes
- `effort` (string): Reasoning effort for this role, mapped to the harness's own control at dispatch: low, medium, high or xhigh, and also max on claude-code. A value the harness does not take is refused at dispatch.
- `harness` (string): The code harness this role runs on for this mission
- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-353 or WEB-42
- `model` (string): The model id this role uses for this mission. The harness must support it
- `projectId` (string, required): Project id the mission belongs to
- `promptContent` (string): Inline prompt-experiment body, capped at 30,000 characters. Mutually exclusive with promptPath.
- `promptMode` (string): How this prompt relates to the repo's own .ship/agents/<role>.md (or ship.yml-pointed) layer. replace (default) makes this the role's only role-prompt layer; extend resolves the repo's layer first an…
- `promptPath` (string): Repo-relative path to an L2 prompt file. Without promptRef this is the SHIP-347 pointer form (resolved at the pinned base branch); with promptRef it's a path+ref experiment resolved at that ref.
- `promptRef` (string): Git ref for promptPath — only meaningful alongside promptPath.
- `rejectOn` (string): Review rejection threshold — only meaningful on the reviewer role
- `role` (string, required): The role this override entry patches
- `sandbox` (string): Sandbox name or id this role starts in for this mission (beats ship.yml and the project default)
- `size`: Container size for this role on this mission

### `get_agents_override` (~77 tokens)

Read a mission's agents-override

Read the per-issue agents/baseBranch override record for one mission, or null when unset.

Input parameters:

- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-353 or WEB-42
- `projectId` (string, required): Project id the mission belongs to

### `send_mission_instruction` (~214 tokens)

Send a follow-up instruction to a mission

Tell a mission what to change. Use kind='follow_up' (the default) to ask for a change: the instruction reaches the agents AND dispatches the builder against the mission's open pull request, overriding cached review and QA verdicts. Use kind='note' to record context for whatever runs next without starting any work. A restart is a different thing: it re-evaluates an unchanged pull request against its cached verdicts, and so changes nothing. Returns a receipt saying what was recorded and what it will cause. This tool calls the SHIP API, documented at https://letsship.ai/docs/api. Requires the missions:write token scope.

Input parameters:

- `body` (string, required): What the agents should do. Travels verbatim into the prompt
- `issueId` (string, required): Issue id the mission is tracked under, e.g. SHIP-244 or GH-1280
- `kind` (string): follow_up (default) dispatches the builder; note records context and dispatches nothing

### `clear_agents_override` (~76 tokens)

Clear a mission's agents-override

Delete the per-issue agents/baseBranch override — the mission resolves from ship.yml again.

Input parameters:

- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-353 or WEB-42
- `projectId` (string, required): Project id the mission belongs to

### `list_missions` (~152 tokens)

List missions

List missions in the caller's accessible projects, newest activity first, with total for paging. Each has issueId, title, activity (what it does now), pipelineProgress, review/check/test state, PR, cost and paused. Archived missions are left out. Requires the missions:read scope.

Input parameters:

- `activity` (string): Filter by what the mission does now
- `limit` (integer): Page size (default 25). Narrow with projectId, activity or search before raising it.
- `offset` (integer): Rows to skip, for the next page
- `projectId` (string): Filter to one project id
- `search` (string): Match the issue id, title, owner or repository

### `get_mission` (~221 tokens)

Get mission detail

Fetch one mission. view='summary' (the default, small enough to poll) returns its summary (activity, stage, review/check/test state, PR, paused and pauseSource, cost), its agent runs (sandboxId, role, status, harness, model, cost) and proofRunSandboxId (pass it to list_artifacts as sandboxId for the proof). view='full' adds its stages, events, stats and the plan/review/QA outcomes. pauseSource 'checkpoint:<role>' means a checkpoint holds it: resume_mission approves that stage. Requires the missions:read scope.

Input parameters:

- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-412
- `orgSlug` (string): Narrow an issue id to one org
- `projectId` (string): Narrow an issue id that two projects share
- `view` (string): summary (default) for the state, runs and proof run; full for every stage, event and outcome

### `pause_mission` (~81 tokens)

Pause a mission

Hold a mission before its next stage. The stage that runs now finishes; no agent is stopped. Use resume_mission to continue. Requires the missions:write scope and a role that can control missions.

Input parameters:

- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-412

### `resume_mission` (~97 tokens)

Resume a mission

Continue a paused mission. When a checkpoint holds it (get_mission shows pauseSource 'checkpoint:<role>'), this approves that stage's result and starts the next stage. To ask for changes to the result instead, use send_mission_instruction. Requires the missions:write scope.

Input parameters:

- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-412

### `stop_mission` (~93 tokens)

Stop a mission

Hard-stop a mission: every agent run of it stops and its work in progress is lost. The pull request stays open, and start_mission starts the mission again. To stop one agent run only, use stop_agent_run. Requires the missions:write scope.

Input parameters:

- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-412

### `approve_mission_ceiling` (~130 tokens)

Let a mission continue past its credit limit

A mission that reached its credit limit pauses until a member lets it continue. This raises the mission's limit by one step and runs the stage that stopped again, so it spends credits: ask the person first. Returns the new limit. Answers 409 when the mission is not at its limit. Requires the missions:run scope.

Input parameters:

- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-412
- `projectId` (string, required): Project id the mission belongs to (get_mission's summary.projectId)

### `merge_mission` (~119 tokens)

Merge a mission's pull request

Merge the mission's open pull request on GitHub with the repository's own merge method; the mission then becomes done, and the merge cannot be undone from here. Answers 409 with the reason when the pull request cannot merge. On a merge conflict SHIP starts the builder to fix it and merges once the mission is ready again, with no further call. Requires the missions:write scope.

Input parameters:

- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-412

### `decline_mission` (~74 tokens)

Decline a mission's pull request

Close the mission's open pull request on GitHub without merging it; the mission becomes declined, and no call here reopens it. Requires the missions:write scope.

Input parameters:

- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-412

### `set_mission_auto_merge` (~131 tokens)

Turn auto-merge on or off for one mission

Set whether SHIP merges this mission's pull request by itself once the checks, the review and the test pass. The setting is for this mission only and replaces the project's auto-merge for it; get_project shows the project's. While it is on, SHIP merges without asking again. Requires the missions:write scope.

Input parameters:

- `enabled` (boolean, required): true merges the pull request once it is ready; false leaves the merge to a person
- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-412

### `archive_mission` (~82 tokens)

Archive a mission

Hide a finished mission from list_missions and the board. Nothing else changes: unarchive_mission shows it again. Requires the missions:write scope and the config:write capability (an owner or admin).

Input parameters:

- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-412

### `unarchive_mission` (~68 tokens)

Unarchive a mission

Show an archived mission in list_missions and on the board again. Requires the missions:write scope and the config:write capability.

Input parameters:

- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-412

### `set_mission_disposition` (~177 tokens)

Record why a mission ended

Record a person's reason for how a mission ended, which the delivery statistics use: product (real work, judged on its merits), probe (a test on purpose), superseded (another mission replaced it: give supersededBy) or takeover (a person finished the work outside SHIP); null clears it. Set it only with the person's answer, never from your own guess. Requires the missions:write scope and the config:write capability.

Input parameters:

- `disposition` (required): product, probe, superseded or takeover; null clears a disposition set by mistake
- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-412
- `supersededBy` (string): The issue id of the mission that replaced this one, for disposition superseded only

### `list_scheduled_tasks` (~64 tokens)

List scheduled tasks

List recurring agent missions (scheduled tasks) across the caller's accessible projects — schedule, enabled state, and next/last fire time for each. Pass projectId for the tasks of one project.

Input parameters:

- `projectId` (string): Only the scheduled tasks of this project

### `list_scheduled_task_templates` (~65 tokens)

List scheduled task templates

Read-only gallery of curated scheduled task templates — a prepared prompt plus a suggested cadence. A template is content, not a code path: pass its key as templateKey on create_scheduled_task for attribution, or copy its prompt/schedule into a hand-written scheduled task.

### `get_scheduled_task` (~96 tokens)

Get scheduled task

Fetch one scheduled task by id: its project, name, prompt, triggers (schedule), labels, template key, skip-if-previous-open setting, enabled state, and next/last run times. An id outside the caller's accessible projects returns not found. For what each fire produced, use list_scheduled_task_runs.

Input parameters:

- `scheduledTaskId` (string, required): Scheduled task id, e.g. from list_scheduled_tasks

### `create_scheduled_task` (~392 tokens)

Create a scheduled task

Create a recurring agent mission. Firing it — on schedule, or immediately via run_scheduled_task — creates an ordinary tracker issue assigned to the agent, which drives a normal pipeline run: a scheduled task is a stored mission request, not a new execution mode. This tool calls the SHIP API, documented at https://letsship.ai/docs/api. Requires the config:write capability.

Input parameters:

- `dayOfMonth` (integer): Day of month, 1-28 — required when interval is 'monthly' (capped at 28 so every month has the day).
- `enabled` (boolean): Whether the schedule is armed (default true)
- `interval` (string, required): Fire cadence. 'weekly' requires weekday; 'monthly' requires dayOfMonth.
- `labels` (array): Tracker label names put on every issue this scheduled task files (default none). The label must ALREADY exist in the project's tracker team — the platform attaches labels but cannot create them, so a…
- `name` (string, required): Scheduled task name, shown in the console and used in the issue title
- `projectId` (string, required): Project id the scheduled task belongs to
- `prompt` (string, required): Becomes the created issue's description verbatim on every fire
- `skipIfPreviousOpen` (boolean): Skip a scheduled fire while the previous fire's mission is still open (default true — the guardrail is opt-out, not opt-in)
- `templateKey` (string): Attribution only, when authored from a template — see list_scheduled_task_templates
- `time` (string, required): 24-hour wall-clock time in `timezone`, e.g. '09:00'.
- `timezone` (string, required): IANA timezone id, e.g. 'Europe/Amsterdam'.
- `weekday` (string): Day of week — required when interval is 'weekly'.

### `update_scheduled_task` (~368 tokens)

Update a scheduled task

Patch a scheduled task's name, prompt, schedule, skip-guard, or enabled state — only the fields passed are changed. To change the schedule, set interval/time/timezone together (plus weekday or dayOfMonth as the interval requires). This tool calls the SHIP API, documented at https://letsship.ai/docs/api. Requires the config:write capability.

Input parameters:

- `dayOfMonth` (integer): Day of month, 1-28 — required when interval is 'monthly' (capped at 28 so every month has the day).
- `enabled` (boolean): Set false to pause the schedule without deleting the scheduled task
- `interval` (string): Fire cadence. 'weekly' requires weekday; 'monthly' requires dayOfMonth.
- `labels` (array): Tracker label names put on every issue this scheduled task files (replaces the list; [] clears it). The label must ALREADY exist in the project's tracker team — the platform attaches labels but canno…
- `name` (string): Scheduled task name, shown in the console and used in the issue title
- `prompt` (string): Replaces the issue description verbatim
- `scheduledTaskId` (string, required): Scheduled task id to update
- `skipIfPreviousOpen` (boolean): Skip a scheduled fire while the previous fire's mission is still open (default true — the guardrail is opt-out, not opt-in)
- `time` (string): 24-hour wall-clock time in `timezone`, e.g. '09:00'.
- `timezone` (string): IANA timezone id, e.g. 'Europe/Amsterdam'.
- `weekday` (string): Day of week — required when interval is 'weekly'.

### `run_scheduled_task` (~99 tokens)

Run a scheduled task now

Fire a scheduled task immediately, bypassing both its schedule and the skip-if-previous-open guard — an explicit run always creates a new issue even while a prior fire's mission is still open. Requires the pipeline:control capability and, for a token caller, the missions:run scope — the same authorization starting a mission by hand requires, because it is the same act.

Input parameters:

- `scheduledTaskId` (string, required): Scheduled task id to fire

### `list_scheduled_task_runs` (~146 tokens)

List a scheduled task's run history

Run history for one scheduled task, each row's status (dispatching/dispatched/skipped/failed) and, once its issue exists, the joined mission progress/cost. A 'dispatched' status means the issue was created and the mission started — never that the work succeeded; read the joined mission state for that. Newest first; when older runs exist, pass nextCursor back as cursor for the next page.

Input parameters:

- `cursor` (string): nextCursor from the previous page; omit for the newest runs
- `limit` (integer): Runs per page, 1-200 (default 50)
- `scheduledTaskId` (string, required): Scheduled task id

### `delete_scheduled_task` (~76 tokens)

Delete a scheduled task

Delete a scheduled task and its run history, which no call can bring back. Missions it already started continue. Setting enabled to false stops new runs and keeps the task and its history. Requires the scheduled-tasks:write scope and the config:write capability.

Input parameters:

- `scheduledTaskId` (string, required): Scheduled task id to delete

### `list_mcp_servers` (~108 tokens)

List a project's MCP servers

The MCP servers a project's repository declares in its MCP file (.mcp.json by default), each with its binding: enabled roles, transport, status, approved tools, per-role effective tool counts (null when the server runs inside the sandbox and the role gets every tool it exposes), and the NAMES of the credential fields set (never values). Also reports whether the file could be read (configStatus).

Input parameters:

- `projectId` (string, required): Project id, e.g. from list_projects

### `list_mcp_bindings` (~75 tokens)

List the org's MCP bindings

Every MCP server binding across the projects you can see in your org: project, server, transport, status, enabled roles, how it authenticates, and the NAMES of the credential fields set (never values). Use it to find where a credential is used; use list_mcp_servers for one project's full detail.

### `set_mcp_config_path` (~127 tokens)

Set a project's MCP file path

Point the project at the repository file that declares its MCP servers, e.g. .cursor/mcp.json or .vscode/mcp.json. null restores the default (.mcp.json). The file is read, never edited. When the repository's ship.yml sets mcp.config, that wins and this call is refused (409); list_mcp_servers reports which one applies as configPathSource. Requires the config:write capability.

Input parameters:

- `configPath` (required): Repository-relative path, or null
- `projectId` (string, required): Project id, e.g. from list_projects

### `bind_mcp_server` (~394 tokens)

Bind an MCP server

Create or update the binding for a server the repository declares. roles is the full set of pipeline roles that may use it (reviewer and qa only ever receive read-only tools, and cannot use a server that runs inside the sandbox). transport: 'remote' (the gateway proxies to the server's URL), 'isolate' (the gateway runs the server's npm package in isolation, for a command that needs a secret) or 'local' (the command runs inside the sandbox, no credential). Omit transport and remoteUrl on an update to keep the server the binding is pinned to, with its credential (a roles, tools or credential edit); set them only to bind or re-point the server. Requires the config:write capability.

Input parameters:

- `approvedTools` (array): The approved subset of the tool snapshot (refresh_mcp_server_tools first). Omit to keep it.
- `credential`: Write-only credential the gateway attaches; agents never receive it. Omit to keep the stored one. OAuth credentials are not set here: bind as remote with kind 'none', then start_mcp_server_oauth.
- `projectId` (string, required): Project id, e.g. from list_projects
- `remoteUrl` (string): A fixed https URL: a hosted endpoint for a command server, or an override for a URL server
- `roles` (array, required): Every role that may use the server ([] disables it)
- `serverName` (string, required): Server name as the repository's MCP file declares it (see list_mcp_servers)
- `transport` (string): How the gateway reaches the server: 'remote' proxies to remoteUrl, 'isolate' runs the server's npm package away from the sandbox so a secret stays out of it, and 'local' runs the command inside the s…

### `unbind_mcp_server` (~92 tokens)

Remove an MCP server binding

Delete a binding and its stored credential: no role receives the server from its next run. The repository's MCP file is not changed, so the server can be bound again. Requires config:write.

Input parameters:

- `projectId` (string, required): Project id, e.g. from list_projects
- `serverName` (string, required): Server name as the repository's MCP file declares it (see list_mcp_servers)

### `refresh_mcp_server_tools` (~106 tokens)

Refresh an MCP server's tool list

Snapshot the bound server's current tools (with their readOnlyHint / destructiveHint annotations) for approval. Approvals of tools that no longer exist are dropped. The binding must be ready; a server inside the sandbox has no gateway tool list. Requires config:write.

Input parameters:

- `projectId` (string, required): Project id, e.g. from list_projects
- `serverName` (string, required): Server name as the repository's MCP file declares it (see list_mcp_servers)

### `start_mcp_server_oauth` (~168 tokens)

Start OAuth for a remote MCP server

Begin the OAuth consent for a server bound as remote. Returns an authorizeUrl that a HUMAN must open in a browser signed in to the SHIP console as the same user this token acts for; the provider returns to the console, which stores the credential. The link is single-use and expires (expiresAt). An agent cannot complete the consent itself. Requires config:write.

Input parameters:

- `projectId` (string, required): Project id, e.g. from list_projects
- `returnTo` (string): Console path to land on after consent, e.g. /projects/<id>
- `scope` (string): Requested scope; defaults to the server's own hint
- `serverName` (string, required): Server name as the repository's MCP file declares it (see list_mcp_servers)

### `list_agent_runs` (~233 tokens)

List agent runs

List the agent runs, live and finished, in the caller's accessible projects, newest first. Each run is one agent in its own sandbox. Returns id (the run's sandbox id), issueId, role, harness, status, instance type, and latest CPU/memory/disk metrics. When more runs match, nextCursor is set: pass it back as cursor, with the same filters, for the next page.

Input parameters:

- `cursor` (string): nextCursor from the previous page; omit for the newest runs
- `issueId` (string): Only the runs of this mission, by its issue id, e.g. SHIP-412
- `limit` (integer): Max results (default 50). Narrow with projectId, issueId, role or status before raising it.
- `projectId` (string): Filter to one project id
- `role` (string): Only the runs of this agent role
- `status` (string): Filter by how the run stands: running, completed (finished), stopped (ended on purpose before it finished), failed, or stale (closed without a report)

Output parameters:

- `data` (array)
- `nextCursor` (string|null)

### `get_agent_run` (~98 tokens)

Get agent run detail

Fetch one agent run: its run record, metric series (CPU/mem/disk over time), and the agent session summaries (role, outcome, cost, sessionId). sessions lists every session of the run's role on the mission; runSessionId names this run's own, so read its log and cost from that one.

Input parameters:

- `sandboxId` (string, required): Agent run id: the run's sandbox id, from list_agent_runs

### `get_agent_run_logs` (~166 tokens)

Get agent run logs

Fetch a session's log content from one agent run. part=session is the agent stream-json (reasoning + tool calls); part=system is the container/runner stdout (clone, dependency install, validation gate, git, callback); part=prompt is the assembled input prompt. The role and sessionId are fields of the agent run's own record. A log longer than 40,000 characters returns its end, from a whole line, with a note.

Input parameters:

- `part` (string): Which log stream to read
- `role` (string, required): Agent role: planner | builder | reviewer | qa
- `sandboxId` (string, required): Agent run id: the run's sandbox id
- `sessionId` (string, required): Session id from get_agent_run's sessions list

### `watch_agent_run` (~231 tokens)

Watch an agent run

Wait on one agent run and follow what its agent does, instead of polling get_agent_run. The call returns when the run ends, when its mission moves to another stage, or after maxSeconds. While it waits, each agent event (a thought, a tool call, a plan update, an error) is sent as a progress notification when the request has a progress token. The result has the status of the run, the stage of its mission, ended, the reason it returned, the last 20 events and a cursor. When the run is still running, call it again with since set to the cursor. A run that already ended returns at once. If your client ends a call after 60 seconds, set maxSeconds below that.

Input parameters:

- `maxSeconds` (integer): The longest time to wait, in seconds (default 300, at most 600)
- `sandboxId` (string, required): Agent run id: the run's sandbox id, from list_agent_runs or get_mission
- `since` (integer): The cursor from an earlier result. Only the events after it are sent

Output parameters:

- `cursor`: The id of the last event. Give it as since to continue
- `ended` (boolean): True when the run is no longer running
- `events` (array): The last 20 events at most, oldest first
- `hint` (string): What to do next, when the run is still running
- `reason` (string): Why the call returned: the run ended, its mission moved to another stage, or maxSeconds passed
- `sandboxId` (string)
- `stage`: The stage of the run's mission when the call returned
- `status` (string): The status of the run when the call returned

### `stop_agent_run` (~101 tokens)

Stop an agent run

Stop the agent in one run before it finishes. Its work in progress is lost, and the run's status becomes stopped a few seconds later. Needs an org admin and the sandboxes:stop scope. This stops one agent run, not the mission: to stop the whole mission, use POST /v1/missions/{issueId}/stop.

Input parameters:

- `sandboxId` (string, required): Agent run id: the run's sandbox id, from list_agent_runs

### `list_sandbox_templates` (~34 tokens)

List custom sandboxes

List the org's sandboxes (definitions agents start in), with each one's active version, size and latest build status.

### `get_sandbox_capacity` (~81 tokens)

Read how many agents are running

How many agents the org's missions are running at once against its limit (null while the org is unclassified), which missions wait for an agent slot and why, and whether every slot on the platform is taken. Read from the platform's once-a-minute capacity check.

Input parameters:

- `orgId` (string): Required only for a caller in several orgs

### `list_sandbox_starters` (~32 tokens)

List sandbox starters

Ready-made sandbox definitions (Python, Java, Go, Rust, Ruby) to create a sandbox from.

### `list_sandbox_template_versions` (~46 tokens)

List a sandbox's versions

Every saved version of a sandbox, newest first, with the active one marked and each one's latest build.

Input parameters:

- `templateId` (string, required): Sandbox id (sbt_...)

### `get_sandbox_build_log` (~81 tokens)

Read a sandbox build's log

A page of a build's log after sequence number `after`. Call again with after = nextAfter until done is true.

Input parameters:

- `after` (integer): Return chunks after this sequence number (default 0)
- `buildId` (string, required): Build id (tbd_...)
- `templateId` (string, required): Sandbox id (sbt_...)

### `save_sandbox_template` (~201 tokens)

Create or update a sandbox

Create a sandbox (omit templateId) or change one. A definition is Dockerfile steps on the platform base (RUN, ENV, ARG, WORKDIR, USER; no FROM). A changed definition or size becomes a new version and is built at once; the response carries that build. Refusals name the line or the size bound.

Input parameters:

- `dockerfile` (string): The Dockerfile that builds the sandbox image. Give this or starterId to create; it replaces the file on an update
- `name` (string): Required when creating
- `size`: A tier, or { vcpu, memoryMib, diskMb } within 1-4 vCPU, >=3072 MiB per vCPU, <=12288 MiB, 8000-20000 MB
- `starterId` (string): Create from a starter's definition and size
- `templateId` (string): Sandbox id (sbt_...)

### `activate_sandbox_template_version` (~65 tokens)

Roll a sandbox back (or forward) to a version

Make a version the one missions use from their next dispatch. It is rebuilt only if its snapshot is gone; the response says which.

Input parameters:

- `templateId` (string, required): Sandbox id (sbt_...)
- `versionId` (string, required): Version id (stv_...)

### `build_sandbox_template` (~40 tokens)

Build a sandbox now

Build the sandbox's active version, or return the build already running for it.

Input parameters:

- `templateId` (string, required): Sandbox id (sbt_...)

### `list_sandbox_registries` (~35 tokens)

List private registries

The org's private package registries sandboxes install from: host, auth scheme, username. Never the secret.

### `save_sandbox_registry` (~114 tokens)

Store a private registry credential

Store (or replace) the credential for a registry host. The platform attaches it to sandbox requests for that host only; it never enters a sandbox and is never returned.

Input parameters:

- `host` (string, required): Registry host or URL, e.g. npm.pkg.github.com
- `scheme` (string, required): How the registry takes the credential: 'bearer' sends secret as a token, 'basic' sends username and secret
- `secret` (string, required): Token or password
- `username` (string): Required for basic

### `delete_sandbox_template` (~84 tokens)

Delete a sandbox

Delete a sandbox with all its versions and builds. Answers 409 while an agent or a project's default sandbox uses it: point those at another sandbox first (update_project with defaultSandboxTemplateId). Missions that run in it now finish. Requires the agents:write scope and the config:write capability.

Input parameters:

- `templateId` (string, required): Sandbox id (sbt_...)

### `delete_sandbox_registry` (~74 tokens)

Remove a private registry credential

Delete the stored credential of a private registry (an id from list_sandbox_registries). A sandbox build that installs from that host then gets no credential. Requires the connectors:write scope and the config:write capability.

Input parameters:

- `registryId` (string, required): Registry credential id, from list_sandbox_registries

### `list_environments` (~104 tokens)

List preview environments

List per-mission preview environments for the caller's accessible projects. Returns id, issueId, projectId, prNumber, workerName, and lifecycle status.

Input parameters:

- `issueId` (string): Filter to one issue id
- `limit` (integer): Max results (default 50). Narrow with issueId, projectId or status before raising it.
- `projectId` (string): Filter to one project id
- `status` (string): Filter by lifecycle status

Output parameters:

- `data` (array)
- `nextCursor` (string|null)

### `get_environment` (~38 tokens)

Get preview environment detail

Fetch one preview environment's registry row (status, worker name, timestamps).

Input parameters:

- `environmentId` (string, required): Environment id (from list_environments)

Output parameters:

- `environment` (object)

### `destroy_environment` (~51 tokens)

Destroy a preview environment

Request teardown of a preview environment (its deployed Worker(s) + every provisioned datastore). Enqueues to the orchestrator; requires project write capability.

Input parameters:

- `environmentId` (string, required): Environment id to tear down

### `list_artifacts` (~211 tokens)

List artifacts

List proof-of-work artifacts (QA screenshots/video/traces) for the caller's accessible projects. Each row carries kind, content type, caption, the acceptance criterion it proves, the sandboxId of the agent run that produced it, and a long-lived signed serving url. Filter by issueId to get one ticket's evidence: the artifacts of every run, superseded QA attempts included, up to limit; a note says when more exist. For the mission's proof of work specifically, read proofRunSandboxId from GET /v1/missions/{id} and pass it as sandboxId.

Input parameters:

- `issueId` (string): Filter to one issue (e.g. SHIP-133)
- `limit` (integer): Max results (default 50). Narrow with issueId or sandboxId before raising it.
- `projectId` (string): Filter to one project id
- `sandboxId` (string): Filter to ONE agent run's artifacts (e.g. the mission's proofRunSandboxId)

Output parameters:

- `data` (array)
- `nextCursor` (string|null)

### `get_artifact` (~44 tokens)

Get artifact

Fetch one artifact's metadata + a long-lived signed serving url (open it to view the screenshot/video).

Input parameters:

- `id` (string, required): Artifact id (from list_artifacts)

Output parameters:

- `caption` (string|null)
- `contentType` (string)
- `createdAt` (string)
- `criterion` (string|null)
- `criterionPassed` (boolean|null)
- `expiresAt` (string|null)
- `id` (string)
- `issueId` (string)
- `kind` (string)
- `projectId` (string)
- `role` (string)
- `sandboxId` (string|null)
- `sessionId` (string|null)
- `sizeBytes` (integer)
- `traceViewerUrl` (string|null)
- `url` (string)

### `inspect_mission` (~166 tokens)

Inspect mission

Fetch the typed platform-inspection report for a mission, by its issue id. Returns per-section KV/D1/R2 state: task state, retry reason, dispatch error, latest review + QA verdicts, run index, per-attempt provenance, running sandboxes, and session-log heads. Requires the inspect:read scope.

Input parameters:

- `issueId` (string, required): The mission's issue id: a Linear key or a GitHub Issues id, e.g. SHIP-199 or WEB-42
- `orgSlug` (string): Narrow an ambiguous issue code to one org
- `projectId` (string): Scope to a specific project id
- `sections` (string): Comma-separated section filter (default all): taskState,retryReason,provenance,…

### `list_orgs` (~117 tokens)

List every org (cross-tenant)

List every organization on the platform with its owner email, member count, and pending invite status. Requires platform-admin (cross_org) access. Cursor-paginated (default page size 50) — feed the response's nextCursor back as the cursor input to reach the next page; a null nextCursor means there are no more pages.

Input parameters:

- `cursor` (string): Opaque page cursor, echoed back as nextCursor by a prior call
- `limit` (integer): Page size, 1-100 (API default 50)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/ai-letsship-ship/mcp#diagnostics

## Score history

- 2026-10-17: 80
- 2026-10-16: 79
- 2026-10-15: 79
- 2026-10-14: 79
- 2026-10-13: 78
- 2026-10-12: 78

## Common questions

### What is the SHIP MCP server?

SHIP is an MCP server listed in the public MCP registry as ai.letsship/ship. Assign Linear, Jira or GitHub issues to an AI coding agent team that plans, builds, reviews, tests. This page covers its hosted endpoint (https://mcp.letsship.ai/mcp).

### Is the SHIP MCP server safe to use?

SHIP scores 80 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the SHIP MCP server expose?

SHIP exposes 72 tools: healthz, whoami, get_setup_progress, get_billing, list_billing_ledger, and 67 more. Their descriptions and schemas cost roughly 9,524 tokens of context every time the server is loaded.

### Does the SHIP MCP server require authentication?

Yes. SHIP asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

### Is the SHIP MCP server still maintained?

SHIP is still listed as active in the MCP registry. We last reached this channel on 17 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://mcp.letsship.ai/mcp
- Repository: https://github.com/letsship/mcp
- Website: https://letsship.ai/docs/mcp
- Changelog RSS feed: https://verifymcp.io/servers/ai-letsship-ship/mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/ai-letsship-ship/mcp.json
- HTML version of this page: https://verifymcp.io/servers/ai-letsship-ship/mcp