Choose what to generate
Decide whether your API needs a CLI, MCP server, native SDKs, or a combination.
Start with how people and agents use your API. Generate only the interfaces they need, then give each one an independent package identity, destination, and release schedule.
Start from the consumer
| Consumer need | Choose | What they receive |
|---|---|---|
| Terminal, scripts, support runbooks, CI, or coding agents | CLI | A focused npm package with typed flags, JSON output, and stable exit codes. |
| Claude, Codex, IDE agents, or another MCP client | MCP | A focused server package plus a hosted endpoint. |
| Application code in TypeScript | TypeScript SDK | An ESM package with typed results and zero runtime dependencies. |
| Application code in Python | Python SDK | A typed synchronous and asynchronous package using the standard library. |
| Application code in Go | Go SDK | A context-first module built on net/http. |
CLI, MCP, and SDK packages are peers. Selecting CLI or MCP does not create, expose, or bill a TypeScript SDK. Each package carries only the request code it needs.
Typeship calls each independently maintained generated product a Target. The name matters when you configure a Project or use the API; it is not another package the customer has to understand.
Common combinations
Public developer platform. Generate a CLI for people and automation, MCP for agent clients, and SDKs for the application languages you support. Each can publish from a dedicated repository.
Internal API. Start with a CLI and hosted MCP when people mostly use the API from terminals and agents. Add an SDK only when an application needs a library dependency.
One language, two audiences. Create two Targets using the same generator when public and internal consumers need different package names, configuration, repositories, or release schedules. They remain separate tgt_* resources even though both use typescript-sdk.
One package in a monorepo. Create one Target with one repository Delivery and set its directory. A Target owns that generated tree. Adjacent Targets need non-overlapping directories.
Target or Delivery?
Create another Target when the generated product needs its own identity or release decision. Add or change a Delivery when that Target needs a destination.
At launch, repository Deliveries use GitHub. The MCP Target also receives a hosted MCP Delivery by default. Repository providers beyond GitHub are not available yet.
typeship targets create prj_... \
--name "Acme Internal TypeScript SDK" \
--definition-id def_... \
--generator typescript-sdk \
--deliveries '[{"kind":"repository","repository":{"provider":"github","identifier":"acme/internal-typescript"},"package_name":"@acme/internal"}]'generator and definition_id cannot change after creation. Configuration, Deliveries, state, generator edition, release channel, and the next proposed version can.
Plans and operation limits
Free lets one linked Project select any of the five Targets. Each Generation contains the first 25 operations and says how many were omitted. The complete Definition is still retained, versioned, and diagnosed.
On Pro, each selected Target is a billing unit. Endpoint usage is counted once from the Project's complete patched Definition, not once per Target. A TypeScript SDK, CLI, and MCP Target are three Targets but do not triple the endpoint count.
List existing Targets before creating one: typeship targets list <project_id>. Create a Target only when identity, configuration, destination, or release history must be independent. Disable it with typeship targets update <target_id> --state disabled to stop future Generations without deleting history.
Add Typeship to an existing API repository
The repository already has the API and its spec. Put the generated package beside it, wire a linked project, and let pull requests keep it current.
Combine API documents
Turn related OpenAPI or GraphQL files into one logical Definition without forcing unrelated APIs into one Project.