MCP server ~ SHIP

The hosted MCP server at mcp.letsship.ai. Connecting a client, the tools it exposes, and a worked hand-off from an assistant that never sees your repository.

SHIP runs a hosted MCP server so an assistant can file missions, follow them and send them feedback without a checkout of your repository in front of it. It is a thin layer over the API: every tool calls one route, and the token you connect with decides what it can reach.

https://mcp.letsship.ai/mcp

Transport is Streamable HTTP. The server is stateless, so there is no session to open, keep alive or clean up, and a client can reconnect at any point without losing anything.

Connect a client

Authentication is a bearer token on every request. Most clients take a remote server as a URL plus headers:

{
  "mcpServers": {
    "ship": {
      "url": "https://mcp.letsship.ai/mcp",
      "headers": {
        "Authorization": "Bearer pat_your_token_here"
      }
    }
  }
}

A client that only speaks stdio can bridge to it with mcp-remote, passing the same header.

Call whoami first. It answers with the principal behind the token and the scopes it carries, which turns "the assistant says it is connected" into something you can actually check. For a monitor with no token to offer, the server answers an unauthenticated GET https://mcp.letsship.ai/healthz; everything at /mcp requires the bearer.

tip

Mint the token bound to one project. Every mission, run, environment, artifact and automation it can reach is then confined to that project, which is the grant worth giving anything you did not write yourself. See Authentication.

Tools

These are the tools a project token can call, grouped by what they are for. The tool list is the same for every caller; what a given token may actually do is decided by its scopes and the role behind it. A tool the token cannot use answers with a refusal that names what was missing, rather than failing quietly.

Missions

Tool	What it does
`start_mission`	Hand an existing tracker issue to the fleet. Enter at the planner by default, at the builder with a plan, or at the reviewer or QA stage with an open pull request
`create_mission`	Create the issue and start the run in one call, for work that has no issue yet
`send_mission_instruction`	Tell a running mission what to change, or record a note for whatever runs next
`inspect_mission`	The full record of a run: stages, verdicts, provenance and session logs
`set_agents_override`	Change one role's harness, model, prompt or checkpoint for a single mission, layered over `ship.yml` without changing it
`get_agents_override`	Read the override currently in force for a mission
`clear_agents_override`	Drop the override and fall back to the project's configuration

Projects and proof

Tool	What it does
`list_projects`	The projects the token can reach
`get_project`	One project's configuration and connections
`list_artifacts`	Proof a run produced, such as test traces and screenshots
`get_artifact`	One artifact, with a link to open it

Automations

Tool	What it does
`list_automations`	Recurring missions configured on a project
`get_automation`	One automation, with its schedule and prompt
`create_automation`	Add a recurring mission
`update_automation`	Change a schedule, a prompt, or disable one
`run_automation`	Fire one now, outside its schedule
`list_automation_runs`	What past runs did, and what they cost
`list_automation_templates`	Starting points worth copying

Infrastructure

Tool	What it does
`list_sandboxes`	Agent runs, live and finished
`get_sandbox`	One run's detail and resource use
`get_sandbox_logs`	What an agent did inside a run
`list_environments`	Preview environments deployed for open pull requests
`get_environment`	One preview environment, with its URL
`destroy_environment`	Tear a preview environment down early

Identity

Tool	What it does
`whoami`	The principal behind the token and the scopes it carries
`healthz`	The API's status, environment and version

A worked hand-off

An assistant with no repository access, asked to get a bug fixed. There is no issue yet.

1. Find the project. list_projects gives the id, for the organization the token belongs to.

2. File the work. create_mission with the project id, a title, and a description whose acceptance criteria are written as checkboxes. The tracker parses them the same way it would on an issue a person wrote, and the QA stage grades against them at the end. The reply carries the mission's issue id and a link to the issue it filed.

3. Let it run. The mission plans, builds, opens a pull request, waits for your CI, reviews, deploys a preview and tests against it. This takes tens of minutes, and the assistant does not need to stay resident for any of it.

4. Answer the verdict. When the reviewer asks for something you disagree with, send_mission_instruction with kind: "follow_up" puts the builder back on the open pull request with your instruction, overriding the cached review and QA verdicts. Use kind: "note" to leave context for whatever runs next without starting any work.

Read the receipt that comes back before reporting success to whoever asked. It says what was recorded and what it will cause, and an instruction against a pull request that has already merged dispatches nothing and tells you so.

warning

Do not call start_mission again to deliver feedback. It re-evaluates the mission against its stored state, so an unchanged pull request with verdicts cached at the same commit correctly does nothing. The instruction channel exists because a restart cannot carry a message.

Integrations for choosing between this, the CLI and the raw API.
Authentication for creating a token and choosing its scopes.
Human in the loop for holding a mission at a stage you want to read before it goes on.

MCP server

On this page