The v2.0 API integration guide, published August 2026, matches MCP server v0.5.0 and supersedes the v1.0 guide from July 2026. If you built an integration against v1.0, some tool names in your code no longer exist. The good news: the changes are mechanical, they cluster around the project and build lifecycle, and everything else is untouched.
The migration table
| v1.0 tool | v2.0 replacement |
|---|---|
delete_project | archive_project |
add_story, update_story, delete_story | save_project_requirements (whole-set immutable revision) |
generate_build_plan | prepare_project_build_plans |
approve_build | approve_project_build_plans (plans) + approve_deployment (deploy) |
resolve_destructive_findings | Removed. Destructive findings surface in plan approval |
Two of these deserve a note beyond the rename. First, requirements editing changed shape, not just name: save_project_requirements replaces the project's epics and stories with a new immutable revision each time, and there are no row-level story edit tools any more. Pass an idempotency_key so retries are safe. Second, the old single approve_build is now two decisions made at two different moments: approving the plans before the build starts, and approving the deployment after the artifacts exist. They were always different questions; v2.0 makes them different calls.
Why: the Projects V5 pipeline
The driver behind all five rows is the same. Builds now run through the Projects V5 pipeline as deliveries, tracked by delivery_id and job_id, with responses carrying pipeline_version: "projects_v5". The v2.0 tool set mirrors that lifecycle: immutable requirement revisions in, prepared and approved plans, a server-side build, and a separately approved deployment out. Destructive findings moved to plan approval because that is where a reviewer is already looking, which is what made a standalone resolve_destructive_findings tool redundant. The full argument for this design is in the governed build pipeline post.
What is unchanged
Everything outside the lifecycle rename is as it was in v1.0:
ask_yeti,search_knowledge, andget_documentlist_projects,get_project,create_project, andupdate_projectstart_build,get_build_status, andlist_target_instances- Authentication (API keys and OAuth 2.1), the endpoint, and rate limits
If your integration only asks Yeti questions or searches the knowledge base, v2.0 requires no code change at all.
The one error older integrations will hit
Pre-V5 project UUIDs are not valid on the v2.0 surface. Calls that replay a stored legacy project ID return PROJECT_NOT_FOUND. The fix is to list current projects first and work from the identifiers that call returns, rather than trusting UUIDs persisted by an older integration.
Where to go next
The API reference page carries the connection details, authentication, tool categories, and safety model, and shows how to connect Claude Code and Codex. You can also call tools/list at any time for the live, authoritative schema of every tool.