Ship MCP and CLI from one SDK
Users run MCP in Claude. Your team runs CLI in scripts and CI. Two surfaces, one handler layer, one repo your client owns.
Define handlers once, expose them as MCP tools and CLI subcommands, test both paths before handoff.
The result
One TypeScript SDK in the client repo: MCP tools and CLI commands call the same functions, with connect docs for both surfaces.
What breaks today
Teams ship MCP as a separate hacky server and CLI as a one-off script. Auth diverges. Bugs show up in one surface but not the other. Support cannot reproduce user reports.
Today
MCP server in one folder, CLI in another, different env vars, different error shapes. A user report in Claude cannot be replayed from terminal.
After scope
One package exports handlers. MCP adapter maps tools. CLI maps subcommands. Same tests hit both.
When to use this guide
Pick this workflow if one of these matches your week.
- Users want Claude integration and your team wants scriptable access.
- You already expose a REST or GraphQL API.
- You want one PR the client's dev can maintain.
- You scope five to ten tools, not the entire platform.
How to do it
This is what every Tookay Build ships. Hosted products like Tubask use the same tool-scoping rules on our infrastructure; your code lives in your repo.
- 01
Define core handlers
Each handler takes typed input, calls your API, returns typed output. No MCP or argv logic inside handlers.
- 02
Wire MCP tools
Map each handler to a tool name, JSON schema, and description the model can read. Cap at ten for v1.
- 03
Wire CLI commands
Mirror the same handlers as subcommands with --json output for scripts. Same flags map to the same auth.
- 04
Test and document both
Integration tests per handler. Connect doc for Claude Desktop and Cursor. CLI section in README with three examples.
What good output looks like
Structured enough to forward or build on.
Sample result
Repo layout: packages/sdk/src/handlers/createExport.ts packages/sdk/src/mcp/server.ts packages/sdk/src/cli/index.ts docs/connect-claude.md docs/connect-cursor.md
Test: npm test runs handler tests · npm run mcp:dev for local MCP
Tips that save time
- Docker optional for local MCP testing, not required in production if you ship remote MCP later.
- Keep tool descriptions short. Models pick tools from names and schemas.
- Log request IDs on both MCP and CLI for support replay.
- See the Tubask case study for hosted MCP; Builds follow the same scope shape in your repo.
Common questions
Key takeaways
- MCP is for users in assistants. CLI is for your client's team.
- Same auth and rate-limit logic behind both surfaces.
- Tubask uses the same scoping discipline; your Build lands in your repo instead of hosted.
Continue reading
Related integration guides.
- Which MCP tools to ship first when users ask about Claude6m
A ranked v1 tool list with specs, auth notes, and a fixed Build quote you can checkout without guessing.
- Demo your API in Claude on a sales call5m
A repeatable five-minute demo script: connect MCP once, run two tools live, and send connect docs after the call.
Ready to scope your v1?
Fifteen-minute fit call. Fixed price. MCP and CLI in your repo in ten to fourteen days.