Blog
Why MCP-native, not CLI-native
Engineering2026-05-13 · 6 min read
Most platforms started as web dashboards, added a CLI, and stopped there. We started somewhere else: in your editor, as an MCP server your AI agent can call.
Editors are the new terminal
When Claude Code or Cursor can run tools, an MCP-native service feels closer than the closest CLI. You describe the intent — "deploy this branch to staging" — and the editor handles the rest. No context switch, no copy-paste tokens, no "where is that command again?".
What we built first
- coday_deploy — one tool, repo URL in, live URL out.
- coday_status — current state, last deploy, monthly usage.
- coday_list — every project under one OAuth token.
These three cover 90% of what we actually do day-to-day. We add new tools only when we hit something the agent cannot already wrap.
CLI still exists
For CI and scripting, the CLI is still the right answer. But everything you can do on the CLI, you can do via MCP. That is the bet: one platform, two surfaces, no second-class API.