Status as of May 13, 2026

The MDC MCP RAG Server is mid-port from Node.js to Python, replacing a custom-rolled MCP server with one built on the AgentCore Python SDK + FastMCP. The Node.js server (mcp_server_node/) continues to serve production traffic on AgentCore Runtime <RUNTIME_ID> while the Python port (mcp_server_python/) is validated module-by-module on a parallel staging runtime (<PYTHON_RUNTIME_ID>).

The driving spec is at .kiro/specs/python-mcp-server-port/ (requirements.md, design.md, tasks.md). Each module ports against a parity test framework that compares Python tool output to the live Node.js baseline, so cutover is module-scoped and reversible.

---

Phase	Module	Tools	Status
B1–B3	Foundation + GGSR + SDD	—	✅ committed
B4	Parity framework	—	✅ committed
B11 (early)	utility	4	✅ committed
B5	semantic_search	7	✅ committed
B6	code_analysis	6	✅ committed
B7	graph_rag	9	✅ committed
B8	ee2_compliance	5	✅ committed
B9	operational	4	🔄 in flight
B10a	sdd_workflow	9	pending
B10b	workflow_info	3	pending
B11	github_tools	4	pending
B12	Strands agents integration	—	pending
B13	AgentCore Memory + Cedar policy	—	pending
B14	Deployment + cutover	—	pending

Remaining tools: 16 across three modules (sdd_workflow, workflow_info, github_tools). All three are relatively simple:

• sdd_workflow — mostly filesystem I/O against the existing SessionManager from B3; no new infrastructure
• workflow_info — pure filesystem reads; no data-layer dependency at all
• github_tools — REST calls against the GitHub API; no Neptune or OpenSearch dependency

At the current pace (roughly one phase per session), we are 3–4 more phases from having all 51 tools ported — call it another 2–3 work sessions.

---

The tool ports are the easy part. Three meatier phases remain:

• B12 — Strands Agents. The multi-agent orchestration layer. This is where Tier B consumer agents (EE2 Compliance Analyzer, Build Failure Diagnoser, Code Review Assistant, Onboarding Docent) get built on top of the MCP. Biggest scope of any remaining phase. See the Two-Layer Architecture steering doc for the consumer taxonomy.
• B13 — AgentCore Memory + Cedar Policy. Persistent cross-session memory and per-tool access control. Replaces the current local JSONL session files with managed Memory storage and adds role-based tool restrictions (e.g. EE2 tools restricted to auditors, per-user rate limiting, collection-level data restrictions).
• B14 — Deployment + cutover. Parity tests run against both runtimes for real, module-by-module traffic flip in Kiro's mcp.json. The dual-runtime architecture means each module can be cut over independently and rolled back without affecting the others.

---

After B11 completes, all 51 tools exist in Python. We rebuild the staging runtime, run the full live parity suite, and if it passes cleanly, flip Kiro's config to point at the Python server. B12–B14 can come later as enhancements — at that point we already have full feature parity with the Node.js server, plus all the platform benefits the Python SDK gives us natively (proper /ping handling, no manual SigV4, native boto3 for Neptune, opensearch-py connection pooling, Memory-ready, Cedar-ready).

---

Based on the current cadence:

Milestone	Effort	Outcome
B9 finish + B10 + B11	2–3 focused sessions	51 tools ported, local tests green
First full-suite live parity run	1 session	Deploy, iterate on parity divergences, document
Traffic flip in Kiro	1 session	Production cutover (reversible)
B12–B14	open-ended	Strands agents, Memory, Cedar — delivered as needed, not on the critical path

So "how far out" depends on what counts as done:

• Feature-parity Python server deployed and tested — ~4 more sessions
• Production cutover complete — ~5 sessions
• Full spec including Strands + Memory + Policy — ~10+ sessions spread over months

The first milestone is the one worth anchoring on. Everything past it is optional upgrades.

---

Three reasons drove the decision to abandon the Node.js custom MCP server in favor of the AgentCore Python SDK:

1. Platform alignment. The custom Node.js server fights AgentCore's deployment lifecycle. The Python SDK (BedrockAgentCoreApp) handles the /ping health-check contract natively, manages the startup window, and is what AgentCore is optimized for. We've burned multiple sessions on cold-start timeouts, container size, and connection pool exhaustion that the Python SDK eliminates by design.

2. Connection management for free. opensearch-py and boto3 pool connections natively and respect AWS service quotas. The Node.js port had to roll its own bounded HttpsAgent after hitting the OpenSearch 1000-connection cluster limit (Phase 56). The Python equivalents don't even surface the problem.

3. Multi-agent ecosystem. AgentCore's Strands SDK, Memory, and Cedar policy enforcement are first-class Python. Node.js access to those services requires custom wrappers that drift from the AWS roadmap. The port unlocks the Tier B consumer agent architecture documented in Two-Layer-MCP-Architecture.

The port also delivers a dual-runtime safety net during transition: every change is validated against the live Node.js baseline through the parity framework before any traffic flips, and the Node.js runtime stays available as an instant rollback target.

---

• Spec — .kiro/specs/python-mcp-server-port/ (requirements, design, tasks)
• Steering — .kiro/steering/06-python-port-progress.md (in-repo progress notes with deploy commands)
• Code — mcp_server_python/ (Python port; mcp_server_node/ is the still-running Node.js server)
• Parity framework — mcp_server_python/tests/parity/ (per-module tests, hermetic by default, RUN_PARITY=1 enables live dual-runtime comparison)
• CHANGELOG — CHANGELOG.md at the repo root (every phase tagged with a version: [8.11.0] for B1–B2, [8.12.0] for B3, etc., through [8.18.0] for B9)

---

Last updated: May 13, 2026 — during Phase B9 OperationalTools port.