[codex] Add MCP project management tool

[IlyaasK]

Summary

• Add manage_projects for Kernel project create/list/get/update/delete workflows.
• Register the projects tool through the new MCP capability module stack from PR 1.5.
• Keep project handling isolated in src/lib/mcp/tools/projects.ts so route.ts stays HTTP/auth-only.

Agent Experience / Flow

This PR gives agents a first-class way to discover and select the project boundary before doing resource-scoped work. Projects are the isolation primitive that later tools, especially API-key creation, depend on through project_id.

Typical flow:

1. Agent calls manage_projects list to discover existing projects and avoid creating duplicates.
2. If the user names a project, agent uses query on list or get by known project_id to resolve the exact target.
3. If no suitable project exists, agent calls manage_projects create name=<name> and keeps the returned project_id for downstream tool calls.
4. For project-scoped API keys, agent passes that returned project_id into manage_api_keys create from the next PR.
5. If project metadata needs to change, agent calls manage_projects update project_id=<id> name=<new> or status=archived.
6. Agent only calls delete for scratch or explicitly requested projects, because project deletion affects the resource boundary for other workflows.

Agent ergonomics:

• The action-oriented schema keeps all project lifecycle operations in one tool, but required IDs stay explicit per action.
• List pagination lets agents scan safely before mutating.
• Returning the full project object after create/get/update gives agents a stable project_id handoff to later tools.

Validation

• git diff --check codex/route-tools-breakdown...HEAD
• KERNEL_CLI_PROD_CLIENT_ID=dummy-prod KERNEL_CLI_STAGING_CLIENT_ID=dummy-staging KERNEL_CLI_DEV_CLIENT_ID=dummy-dev NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_Y2xlcmsuZXhhbXBsZS5jb20k bun run build
• python3 /Users/ilyaas/.codex/skills/autoreview/scripts/autoreview --mode branch --base codex/route-tools-breakdown
• localhost MCP CRUD smoke against http://127.0.0.1:3002/mcp with API_BASE_URL=http://127.0.0.1:3001: initialized MCP, verified manage_projects was listed, created a scratch project, got/updated/listed/deleted it, and confirmed post-delete get failed as expected

---

Note

Medium Risk
Introduces authenticated create/update/delete against org projects; mistakes or overly broad MCP access could change isolation boundaries, though behavior mirrors existing MCP tool patterns.

Overview
Exposes Kernel project lifecycle over MCP via a new manage_projects tool (create, list, get, update, delete), including list pagination and archive-by-status on update.

Wires it in through registerProjectCapabilities in register.ts, with implementation isolated in projects.ts using the authenticated Kernel client like other MCP tools.

^{Reviewed by Cursor Bugbot for commit 608f5aa. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
mcp	Ready	Preview, Comment	Jun 1, 2026 5:53pm

[firetiger-agent]

Monitoring Plan: MCP Server Tool Registration Refactored into Modules

What this PR does: Reorganizes internal MCP server code — moves tool, resource, and prompt registration from a single large file into separate module files. No tools added or removed, no user-visible behavior change intended.

Intended effect:

• Railway HTTP 5xx rate: baseline 0.0017–0.0039% (~4–9 errors/hr); confirmed if rate stays below 0.01% post-deploy
• MCP transport endpoint availability: baseline — low but steady traffic on MCP paths; confirmed if any MCP calls continue to return expected 200/401 responses (no new 500s)

Risks:

• Module initialization failure — if any registerX() call throws at startup, all MCP requests return 500; alert if Railway 5xx rate exceeds 0.01% for 30+ minutes post-deploy
• Profiles resource removal — profiles:// MCP resource was present in the old code but is absent from the new resources.ts; alert if any "resource not found" errors appear for profile URI lookups
• Import alias failure — @/lib/mcp/... path aliases must resolve at Next.js build/runtime; alert if any 500s appear immediately after deploy with module-not-found errors in logs
• Specific tool regression — any of the 11 newly-modularized tool files could have a subtle handler difference; alert if Railway 5xx rate on MCP paths rises above zero from baseline

Status updates will be posted automatically on this PR as monitoring progresses.

View monitor

The base branch was changed.

[firetiger-agent]

MCP tool registration refactor deployed cleanly at 2 minutes post-deploy in Production.

Signals (all healthy):

• Railway HTTP 5xx rate: 0.0068% (within pre-deploy baseline 0.0018–0.0076%, below 0.01% alert threshold)
• MCP path traffic: Zero 500 responses on /mcp, /sse, /streamable endpoints
• Startup logs: Zero "registerMcpCapabilities", "Cannot find module", or module not found errors

Risks watched (all clean): Module initialization failure, broken tool registration, MCP endpoint errors, profiles resource removal impact

Monitoring continues across 72-hour window.

View monitor

[masnwilliams]

reviewed — clean, follows the house pattern, typechecks, and the SDK calls all line up against @onkernel/sdk@0.58.0. import + registration wired correctly. nothing blocking.

nits (optional)

• src/lib/mcp/tools/projects.ts:152 — error instanceof Error ? error.message : String(error) is actually better than apps.ts which just interpolates ${error}. worth standardizing the codebase on this helper (see #112 which extracts errorMessage).
• no server.resource("projects", ...) companion like apps.ts has — not required (other tools omit it too), just noting the asymmetry.
• register.ts insertion splits registerBrowserCapabilities from registerBrowserPoolCapabilities — purely cosmetic.

agent-fit

lightweight project CRUD — appropriate for an agent. one cross-cutting suggestion that applies to all the new tools: none set MCP tool annotations (readOnlyHint on list/get, destructiveHint on delete). adding them lets clients auto-run reads and prompt on destructive ops — the standard mechanism GitHub/Stripe-style servers rely on. zero behavior change.

[masnwilliams]

approving — clean, follows the house pattern, typechecks, SDK calls verified. only optional nits (see prior review), nothing blocking.