APEX Remote MCP Service Proposal
APEX Remote MCP Service Proposal
Requested By: Robert Matsuoka
Initiative: I-2026-ITP-001
Technical Spec: duetto-code-intelligence/docs/APEX-MCP-SPEC.md
The Problem
APEX adoption is bottlenecked by workflow friction. Creating or updating an artifact today requires: cloning the repo, understanding frontmatter schemas, running local validation, committing, and opening a PR. This works for the 5–6 people who live in APEX, but it's too much for the broader R&D org.
The result: status fields go stale, proposals don't get written, and the product hierarchy is only as current as its most dedicated maintainer.
The Proposal
Extend duetto-code-intelligence (DCI) with an APEX-aware MCP service — available to every Claude Code, Cursor, and Claude Desktop user on the team. The service exposes:
-
An APEX Chat agent (Claude Sonnet 4.6) with deep APEX context, answering questions like "what's in delivery right now?" or "how do I create a PRD?" — and providing links back to canonical Docusaurus pages.
-
APEX MCP tools for read operations (list initiatives, get initiative, list open PRs) available immediately, and write operations (create initiative, create proposal, update status) gated behind a one-time GitHub OAuth connection in DCI Settings.
-
A dedicated
/apexUI in DCI for direct browser-based APEX Chat interaction.
Architecture Summary
Claude Code / Cursor / Claude Desktop
↓ MCP JSON-RPC (HTTPS)
DCI /mcp ─────────────────────────────────────┐
apex_chat → Sonnet 4.6 + APEX prompt│
apex_list_* → APEX repo clone (read) │
apex_create_* → GitHub as the user │
apex_update_status → GitHub as the user │
│
DCI /apex (web UI) ────────────────────────────────┘
Token security: GitHub OAuth tokens stored encrypted (Fernet AES-128-CBC) in DCI DB. Fernet key in AWS Secrets Manager.
What already exists in DCI: MCP endpoint, JWT auth, Google OAuth, AWS Bedrock/Claude, APEX repo sync, APEX reader service. Phase 1 is mostly wiring, not greenfield.
Implementation Plan
Phase 1 — Read + Chat (3–4 days)
- Extend
ApexServicefor full frontmatter parsing - Add
ApexAgentService(Sonnet 4.6 + APEX system prompt) - Add 4 MCP tools:
apex_chat,apex_list_initiatives,apex_get_initiative,apex_list_prs - APEX Chat UI at
/apex
Phase 2 — GitHub OAuth + Writes (3–4 days)
- Register GitHub OAuth App in
duettoresearchorg - Add
GitHubAuthAdapter+ OAuth routes - Extend User model with encrypted
github_access_token - Add 3 write tools:
apex_create_initiative,apex_create_proposal,apex_update_status - "Connect GitHub" flow in DCI Settings
Phase 3 — Polish (1–2 days)
- Initiative dashboard, deep links, rate limiting, audit log
Total: 7–10 engineering days
Success Criteria
| Metric | Target |
|---|---|
| Unique APEX contributors/week | ≥20 (up from ~5) |
| Weekly APEX artifact touches | ≥50 (up from ~10–15) |
| Phase 1 early users | ≥15 in first 2 weeks |
Kill signal: <10 users after 4 weeks of Phase 1 → pause Phase 2.
Scope Boundaries
This is NOT: - A JIRA replacement (JIRA is downstream; APEX is upstream) - A general GitHub integration (APEX repo only) - Real-time sync (nightly sync, same as today)
Open Questions
- GitHub OAuth App registration: Who approves
duettoresearchorg app registrations? (Kartik or Bob?) - Draft PR or push-branch-only?
create_initiativecreates a branch — should the tool also auto-open a draft PR? - Sonnet 4.6 model: Available in DCI's Bedrock region? Or do we need to verify?
- APEX sync frequency: Do write operations need to trigger a sync, or is daily fine for the MVP?
Approval
- [ ] Kartik — Product/architecture approval
- [ ] Bob — CTO approval + GitHub OAuth App registration
This document is DRAFT. See Initiative.md for full detail and the DCI spec for implementation specifics.