MCP server

Hand work to SHIP from the assistant you already use. SHIP hosts this MCP server, so your assistant needs no checkout of your repository. The server is a thin layer over the API, and each tool calls one route. The token that you connect with sets what the tools can reach.

https://mcp.letsship.ai/mcp

The transport is Streamable HTTP. The server is stateless, so there is no session for you to open, keep open or close. A client can reconnect at any time, and it loses nothing.

Connect a client

Each request carries a bearer token for authentication. Most clients accept a remote server as a URL and headers:

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

A client that speaks only stdio can connect through mcp-remote, with the same header.

In Grok, open grok.com/connectors, select New Connector, then Custom, and paste the URL. Grok then asks you to sign in to SHIP. In the xAI API, pass the URL as a remote MCP tool in server_url, and put the token in its headers.

Call whoami first. It returns the principal behind the token and the scopes of the token. With this answer, you can check the connection yourself. You do not have to trust what the assistant says. A monitor that has no token can call GET https://mcp.letsship.ai/healthz, which needs no authentication.

Sign-in and scopes

A client without a token can start the connection and read the tool list. Directories read the list in this way to show what the server does. Every tool call needs a token. A tool call without a token gets HTTP 401, and its WWW-Authenticate header points the client to the sign-in. The header also names the scopes to ask for: projects:read, missions:read, missions:run, missions:write and artifacts:read.

The answer without a token reads nothing from your account. The server holds no token for it and calls nothing in the API. Each caller gets the same list.

Some tools need a scope that is not in that list, such as inspect:read for inspect_mission. If you signed in with OAuth and the token does not have the scope, the call gets HTTP 403 with error="insufficient_scope". The scope value in the header names the scopes of the token and the scope that the call needs. Your client can then ask you to sign in again with the wider grant. This happens only if your role can grant the scope and the client speaks protocol revision 2025-11-25 or later. Otherwise, and for a personal access token, the call returns a refusal that names the scope that the token does not have.

The watch_agent_run tool answers with a stream, and the stream starts before the tool reads the run. So this tool never answers with HTTP 403: it returns the refusal in its result. To get the wider grant, call get_agent_run first. It needs the same sandboxes:read scope.

Choose the tools

A client can ask for fewer tools with two headers. A shorter tool list costs the model fewer tokens and gives it fewer wrong tools to choose from.

The groups follow the sections under Tools, in order: missions, projects, scheduled-tasks, mcp-servers, agent-runs, environments, billing, sandboxes and admin. An unknown group or value gets HTTP 400, with the list of valid values. A client that takes only a URL, such as a hosted connector, gets every tool.

{
  "mcpServers": {
    "ship": {
      "url": "https://mcp.letsship.ai/mcp",
      "headers": {
        "Authorization": "Bearer pat_your_token_here",
        "X-MCP-Toolsets": "missions,projects",
        "X-MCP-Readonly": "true"
      }
    }
  }
}

ChatGPT

ChatGPT connects to its own URL:

https://mcp.letsship.ai/chatgpt/mcp

This URL serves the same server without the three tools for purchases: list_credit_offers (the prices), start_credit_checkout (a payment page) and update_team_subscription (a change of plan). OpenAI does not let an app in ChatGPT sell credits or subscriptions. A person who signs in from ChatGPT still uses what the plan of the workspace includes, and can read the credits or ask for more. On this URL, get_billing gives no plan advice, and the notices from get_notices have no link to buy credits or to pay. Every other client uses https://mcp.letsship.ai/mcp, which has every tool.

The ChatGPT URL is its own OAuth resource, with the same scopes as /mcp. A token that ChatGPT gets at sign-in works only on this URL, and a token for /mcp does not work on it. A personal access token works on both. The two headers in Choose the tools also work on this URL.

Protocol versions

The server speaks MCP 2026-07-28 and the 2025 revisions of the protocol at the same URL. A client that sends the 2026-07-28 request envelope can call server/discover, and its list results carry cache times. A client that starts with initialize gets the 2025 handshake. A revision that the server does not know gets error -32022, with the revisions that it supports. The server card lists the same revisions.

In both revisions, the first answer gives instructions for the model. They say where to start, how a mission runs over time and which tools spend credits.

Results

Tools that only read and return an API object, such as whoami, list_projects and list_agent_runs, declare an output schema. Their result has the object as structuredContent, and as JSON text for a client that reads only text. The schema comes from the API contract, so it matches the API reference. Tools that change something have no output schema. The server checks a result against its schema after the API acts, so a mismatch could show a started mission as a failure.

The server cuts a text result after 60,000 characters and adds a note that says so. For a long log, get_agent_run_logs keeps the end instead, because the end holds the outcome. A result with an output schema cannot be cut, so if it is longer, the call returns a refusal.

To get less, set a smaller limit, a filter or fewer sections. Three lists return 50 rows when you do not set limit: list_artifacts, list_agent_runs and list_environments. A note tells you when more artifacts or environments match. The tools list_agent_runs and list_scheduled_task_runs return a nextCursor while more rows match. Give it back as cursor for the next page. A refusal uses the words of the API: what went wrong, and whether a retry can help.

One tool streams its answer: watch_agent_run. The server answers its call as server-sent events, in both revisions. If the request has a progress token, each event of the agent comes as a progress notification. A comment line comes at least every 15 seconds, so that the connection stays open. The result comes last, when the run ends, when its mission moves to another stage, or after maxSeconds. Every other tool returns one JSON answer.

Tools

A project token can call the tools below, in groups by purpose. Each caller gets the same tool list, unless the client chooses fewer tools. The scopes of a token and the role behind it decide what that token can do. A tool that the token cannot use does not fail quietly. It returns a refusal that names what the token does not have.

Each tool tells the client what it does with three hints: readOnlyHint, destructiveHint and openWorldHint. A client can then run a tool that only reads at once, and ask you before a tool with the destructive hint. The open-world hint marks a tool whose effect leaves SHIP, such as a mission that opens a pull request or a payment page.

Seventeen tools have the destructive hint. Eight of them remove or stop something: clear_agents_override, unbind_mcp_server, stop_agent_run, stop_mission, destroy_environment, delete_scheduled_task, delete_sandbox_template and delete_sandbox_registry. Three replace a stored value that you cannot read back. bind_mcp_server and save_sandbox_registry replace a credential. refresh_mcp_server_tools drops the approvals of tools that the server no longer has.

Two tools change a pull request on GitHub: merge_mission merges it, and decline_mission closes it. Two more let SHIP act on GitHub later without a person. The tool set_mission_auto_merge turns on auto-merge for a mission, and update_project can turn it on for a project or connect another repository. The last two are billing tools: start_credit_checkout opens a payment page, and update_team_subscription changes your plan.

Missions

Projects and proof

Scheduled tasks

MCP servers for your agents

The servers come from your repository's own MCP file, which SHIP reads and never edits. These tools manage the binding of a server: the agents that may use it, the tools that they may call, and its credential. A credential is write-only. No tool returns it.

Agent runs

An agent run is one agent in its own sandbox. The id of a run is its sandbox id, which the console shows in the Sandbox ID field of the run.

These tools had other names before: list_sandboxes, get_sandbox, get_sandbox_logs and stop_sandbox. The old names still work for now, but the tool list does not show them. Use the new names in your prompts and scripts.

Preview environments

Credits and notices

These tools read and change the credits of your workspace. The tools that buy or change a plan need an owner or an admin. A payment page opens in the browser of the person who pays, and SHIP charges nothing until that person pays.

Custom sandboxes

A custom sandbox adds tools to the environment that your agents start in. These tools need a role that can change the configuration of your organization.

Platform operators

Identity

A worked hand-off

In this example, an assistant that has no access to the repository gets a request to fix a bug. There is no issue yet.

1. Find the project. list_projects gives the project id. It lists the projects in the organization that the token belongs to.

2. File the work. Call create_mission with the project id, a title and a description. In the description, write the acceptance criteria as checkboxes. The tracker parses them as it parses an issue that a person wrote, and at the end the Tester grades the work against them. The reply gives the issue id of the mission and a link to the issue that SHIP filed.

3. Let it run. The mission plans, builds, opens a pull request, waits for your CI, reviews the change, deploys a preview and tests the preview. This takes tens of minutes, and the assistant does not have to stay active during that time. To check on the mission later, call get_mission, which gives its stage, its results and its agent runs.

4. Answer the verdict. If the Reviewer asks for a change that you do not agree with, call send_mission_instruction with kind: "follow_up". The Builder then goes back to the open pull request with your instruction. The instruction overrides the cached verdicts of the Reviewer and the Tester. To leave context for the next agent and start no work, use kind: "note".

Before you report success to whoever asked, read the receipt that comes back. The receipt says what SHIP recorded and what the instruction will cause. If the pull request is already merged, the instruction dispatches nothing, and the receipt says so.

Related

• Integrations to choose between this server, the CLI and the raw API.
• Authentication to create a token and choose its scopes.
• Human in the loop to hold a mission at a stage, so that you can read the result before the mission continues.