release: v3.37.0 — MCP vs CLI landing page + guide section

- New guide section: guide/ecosystem/mcp-vs-cli.md (4 decision dimensions, 15-row guidance table, token cost analysis, practitioner quotes) - New landing page: cc.bruniaux.com/ecosystem/mcp-vs-cli/ (4 decision cards, collapsible guidance table, zero JS, WCAG-compliant badges) - ICM v0.5.0 setup guide corrections + icm-session-starter.md template - 3 resource evaluations: mcp2cli, MCPorter, CircleCI MCP vs CLI blog - WP10 v1.2.0 DAF/finance feedback corrections (FR+EN) - Recap cards EN translations (57 cards) + FR version bump 3.32.1 → 3.36.0 - Whitepapers v2.2: 7 WPs synced with guide v3.27.6 → v3.36.0 delta - check-landing-sync.sh: section 7 for MCP vs CLI sync tracking - docs/for-cto.md: whitepapers links updated to florian.bruniaux.com/guides Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-17 15:55:44 +01:00 · 2026-03-17 15:55:44 +01:00 · f5d78e1004
commit f5d78e1004
parent 728431cd4d
14 changed files with 663 additions and 27 deletions
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@ -6,8 +6,29 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).

 ## [Unreleased]

+## [3.37.0] - 2026-03-17
+
+- **ICM v0.5.0 — setup guide + session starter template**: corrected `icm init` documentation (3 explicit modes: `--mode mcp`, `--mode hook`, `--mode skill` — not a single interactive command); fixed CLI syntax (`--importance` is an enum `critical|high|medium|low`, not a float; no `memory` subcommand); added `examples/memory/icm-session-starter.md` ready-to-use onboarding prompt to paste at the start of any session.
+
+- **New guide section — MCP vs CLI Decision Guide** (`guide/ecosystem/mcp-vs-cli.md`): full comparison of MCP servers vs CLI tools across 4 decision dimensions (user type, model capability, observability needs, schema stability), decision matrix by situation, token cost analysis, tooling overview (RTK, MCPorter, mcp2cli), and practitioner quotes. Cross-linked from `mcp-servers-ecosystem.md`. Landing page published at `cc.bruniaux.com/ecosystem/mcp-vs-cli/` with 4 decision cards, 15-row collapsible guidance table, practitioner quotes section, and tooling micro-section. `check-landing-sync.sh` extended with section 7 for MCP vs CLI sync tracking.
+
+- **Resource evaluations (3)**: mcp2cli (3/5, MCP/OpenAPI/GraphQL to runtime CLI, 96-99% token savings claim, 8-day-old tool with structural mismatch against Claude Code native MCP architecture — watch list + document schema overhead insight); MCPorter by Steinberger (3/5, TypeScript MCP toolkit with auto-discovery, CLI generation and TS codegen — useful companion for testing MCP servers and hook scripts); CircleCI MCP vs CLI blog (3/5, inner loop / outer loop decision framework, 6-question guide, directional browser automation benchmark — worth borrowing the vocabulary, not the benchmark numbers).
+
+- **WP10 v1.2.0 — Marc Sélince feedback (DAF/finance)**: 6 corrections FR+EN on `10-budget-ia.qmd` / `10-ai-budget.qmd`. New `## Pour le DAF/CFO` section (ROI + OpEx/CapEx framing, replaces placeholder callout). New `## Freins COMEX au-delà du coût` Q&A section (vendor dependency, IP risk, lock-in pricing). §3.1 reframed "Attraction et rétention des top performers" (market tight for seniors/experts, not all profiles). §3.2 CTO: new "ROI des heures d'ingénieur" sub-point (LLMs on mechanical code free engineering time for architecture). §4.1 Budget: option 4 added (replace paid tool with OS equivalent for net-zero pilot), "200-500$/mois" figure removed from discretionary budget.
+
+- **Recap cards — EN translations created + FR fixes**: 57 EN recap cards created from scratch (`whitepapers/recap-cards/en/`) by translating all FR cards. FR cards batch-updated: `guide-version` and `version` fields bumped `3.32.1` → `3.36.0` across all 57 FR cards. Factual fixes: T19 (context window) corrected "1M beta, API only" → "1M GA for Max/Team/Enterprise CC plans (v2.1.75, no header needed)"; T01 (essential commands) updated with `/plan`, `/effort`, `/branch`, `/rename`, `/loop`, `/voice`, `/fast`, removed non-existent `/cost`, corrected keyboard shortcuts. `docs/for-cto.md` updated: "whitepapers coming soon" → links to `florian.bruniaux.com/guides` in all 4 occurrences.
+
 - **Fix dead link** (`guide/ultimate-guide.md` §3.5): Packmind anchor `../ecosystem/third-party-tools.md#packmind` corrected to `ecosystem/third-party-tools.md#packmind` (wrong `../` prefix was resolving outside `guide/`).

+- **Whitepapers v2.2 — Guide content sync (7 WPs updated)**: synced WP content with guide v3.27.6 → v3.36.0 delta.
+  - **WP00** (v1.2.0): 1M context corrected "beta" → GA (v2.1.75); 7 major features table added (Tasks API, Auto-memories, Agent Teams, LSP Tool, Remote Control, MCP Elicitation)
+  - **WP03** (v1.1.0): PreToolUse security fix callout (v2.1.77 — `"allow"` bypassed enterprise `deny`); `allowRead` sandbox parameter added
+  - **WP05** (v1.2.0): Native Code Review section (Research Preview, Teams/Enterprise) — multi-agent, 3 trigger modes, `REVIEW.md`, ~$15-25/PR pricing
+  - **WP07** (v1.1.0): 12 new slash commands, 7 new hook events, extended CLI flags, Remote Control section, 1M GA correction
+  - **WP08** (v1.2.0): Identity drift after compaction pattern added (UserPromptSubmit hook + agent-identity.txt re-injection)
+  - **WP09** (v1.1.0): Review bottleneck inversion section; Regulatory Exposure section (EU AI Act GPAI/high-risk, FDA AI/ML Guidance)
+  - WP02: no hook events section in scope; WP01/WP04/WP06/WP10: no gaps identified
+
 - **Cheatsheet + reference.yaml maintenance**: date updated February → March 2026 in `guide/cheatsheet.md`; "Command not found" fix updated to use native installer (`curl | sh`); `machine-readable/reference.yaml` `updated` field bumped to 2026-03-17.

 - **Whitepapers v2 — Reviewer corrections** (6 relecteurs: Edouard, Mat, Nicolas, Marc, Anthony, Emmanuel): 8-phase correction plan applied across 10 whitepapers (WP00–WP10) FR+EN.
--- a/README.md
+++ b/README.md
@ -6,7 +6,7 @@

 <p align="center">
  <a href="https://github.com/FlorianBruniaux/claude-code-ultimate-guide/stargazers"><img src="https://img.shields.io/github/stars/FlorianBruniaux/claude-code-ultimate-guide?style=for-the-badge" alt="Stars"/></a>
-  <a href="./CHANGELOG.md"><img src="https://img.shields.io/badge/Updated-Mar_17,_2026_·_v3.36.0-brightgreen?style=for-the-badge" alt="Last Update"/></a>
+  <a href="./CHANGELOG.md"><img src="https://img.shields.io/badge/Updated-Mar_17,_2026_·_v3.37.0-brightgreen?style=for-the-badge" alt="Last Update"/></a>
  <a href="./quiz/"><img src="https://img.shields.io/badge/Quiz-271_questions-orange?style=for-the-badge" alt="Quiz"/></a>
  <a href="./examples/"><img src="https://img.shields.io/badge/Templates-204-green?style=for-the-badge" alt="Templates"/></a>
  <a href="./guide/security/security-hardening.md"><img src="https://img.shields.io/badge/🛡️_Threat_DB-15_vulnerabilities_·_655_malicious_skills-red?style=for-the-badge" alt="Threat Database"/></a>
@ -872,7 +872,7 @@ See [CONTRIBUTING.md](./CONTRIBUTING.md) for guidelines.

 ---

-*Version 3.36.0 | Updated daily · Mar 17, 2026 | Crafted with Claude*
+*Version 3.37.0 | Updated daily · Mar 17, 2026 | Crafted with Claude*

 <!-- SEO Keywords -->
 <!-- claude code, claude code tutorial, anthropic cli, ai coding assistant, claude code mcp,
--- a/2
+++ b/2
@ -1 +1 @@
-3.36.0
+3.37.0
--- a/docs/for-cto.md
+++ b/docs/for-cto.md
@ -25,7 +25,7 @@ Claude Code runs locally. It does **not** send your codebase to Anthropic — on
 - Access control: granular permissions per project, per user, per tool
 - Audit trail: every action logged via hooks

-Full breakdown: WP06 — Privacy & GDPR Compliance *(whitepaper, coming soon)* (20 min)
+Full breakdown: WP06 — Privacy & GDPR Compliance (20 min) — [florian.bruniaux.com/guides](https://www.florian.bruniaux.com/guides)

 ### Threat landscape

@ -35,7 +35,7 @@ This is the only public resource tracking AI coding tool vulnerabilities: **15 v
 - Supply chain attacks via MCP servers (treat like npm packages)
 - Overpermissive configs in CI/CD pipelines

-Mitigation framework: WP03 — Security in Production *(whitepaper, coming soon)* (25 min)
+Mitigation framework: WP03 — Security in Production (25 min) — [florian.bruniaux.com/guides](https://www.florian.bruniaux.com/guides)

 ### Team adoption

@ -43,13 +43,13 @@ The ROI scales with structure. An individual developer gets 2-3× productivity o

 Realistic adoption timeline: 4-6 weeks to full team competency with structured onboarding.

-WP05 — Deploying with a Team *(whitepaper, coming soon)* (25 min)
+WP05 — Deploying with a Team (25 min) — [florian.bruniaux.com/guides](https://www.florian.bruniaux.com/guides)

 ---

 ## Recommended reading path (60 min total)

-> Whitepapers are currently in private access — public release coming soon.
+> Whitepapers are available at [florian.bruniaux.com/guides](https://www.florian.bruniaux.com/guides)

 | Document | Time | What you'll get |
 |----------|------|----------------|
@ -102,7 +102,7 @@ If you want to accelerate adoption or get an independent assessment of your curr

 ## Quick links

- Whitepapers — 10 focused deep-dives *(coming soon)*
+- Whitepapers — 10 focused deep-dives: [florian.bruniaux.com/guides](https://www.florian.bruniaux.com/guides)
 - [Security Hardening Guide](../guide/security/security-hardening.md)

 ← [Back to main README](../README.md)
--- a/docs/resource-evaluations/2026-03-17-circleci-mcp-vs-cli-blog.md
+++ b/docs/resource-evaluations/2026-03-17-circleci-mcp-vs-cli-blog.md
@ -0,0 +1,106 @@
+# Resource Evaluation: "MCP vs. CLI" (CircleCI Blog)
+
+**Date**: 2026-03-17
+**Evaluator**: Claude Sonnet 4.6
+**Resource URL**: https://circleci.com/blog/mcp-vs-cli/
+**Resource Type**: Technical blog post
+**Author**: Jacob Schmitt (CircleCI)
+**Published**: 2026-03-11
+
+---
+
+## Executive Summary
+
+Jacob Schmitt proposes a decision framework for choosing between MCP servers and CLI tools in agentic workflows, using the inner loop / outer loop distinction as the organizing principle. The post includes a browser automation benchmark (CLI 33% better token efficiency, 77 vs 60 task completion), a 6-question decision guide, and a hybrid architecture example from CircleCI's own tooling. The framework aligns with how the guide already positions RTK and the CLI+MCP hybrid approach. The post adds useful external validation and a cleaner decision vocabulary than what currently exists in the guide, but does not introduce new technical ground for experienced Claude Code users.
+
+---
+
+## Content Summary
+
+- **Core thesis**: inner loop (frequent, local, low-latency dev iteration) favors CLI; outer loop (shared systems, CI/CD, cross-team infrastructure) favors MCP
+- **Browser automation benchmark**: single test comparing agentic browser automation via CLI vs MCP. CLI: 77% task completion, 33% better token efficiency. MCP: 60% task completion. Methodology not detailed (single test, CircleCI-internal)
+- **6-question decision framework**:
+  1. Who owns the feedback loop? (developer alone → CLI; multiple agents/team → MCP)
+  2. How often does the schema change? (frequently → CLI overhead lower; stable → MCP investment worthwhile)
+  3. Does the tool require auth/secrets management at runtime? (yes → MCP; no → CLI simpler)
+  4. Do you need structured output consumed by another agent? (yes → MCP; no → CLI)
+  5. Is this a team or individual tool? (team → MCP standardization; individual → CLI flexibility)
+  6. How much context budget do you have? (tight → CLI; ample → MCP acceptable)
+- **CircleCI hybrid model**: Chunk CLI (local file ops) + Local CLI (shell + git) + CircleCI MCP Server (CI/CD system access) — each layer mapped to inner/outer loop
+- **Does NOT mention**: Claude Code, Anthropic, RTK, or any specific tool outside CircleCI's stack
+
+---
+
+## Gap Analysis vs. Guide
+
+| Area | CircleCI post | Guide coverage |
+|------|---------------|----------------|
+| Inner loop / outer loop vocabulary | ✅ Clean framework | ⚠️ Concept exists implicitly, not named this way |
+| Decision framework (when CLI vs MCP) | ✅ 6-question guide | ⚠️ Philosophy covered, structured decision tool not present |
+| Token cost of MCP tool schema | ✅ Mentioned as key driver | ❌ Not quantified anywhere in guide |
+| Browser automation benchmark | ✅ Single data point | ❌ No benchmark data in guide |
+| Hybrid CLI + MCP architecture | ✅ CircleCI example | ✅ Guide covers this philosophically |
+| Claude Code-specific guidance | ❌ | ✅ Guide's primary differentiator |
+
+**Real gap**: the guide lacks a structured decision framework for "should I use an MCP server or a CLI tool for this workflow?" The inner loop / outer loop vocabulary is clean and could be adopted directly, or serve as source inspiration for adding this framing to the guide.
+
+---
+
+## Quality Assessment
+
+**Strengths**:
+- The inner loop / outer loop distinction is well-established in dev productivity literature (ring-fencing fast local iteration vs. shared system operations) and applies cleanly to MCP vs. CLI
+- The 6-question framework is actionable and maps directly to real workflow decisions
+- CircleCI's own hybrid architecture is a credible worked example
+- Published on a high-traffic engineering blog — will be referenced by practitioners
+
+**Weaknesses**:
+- The browser automation benchmark is a single internal test with no methodology disclosure. 77% vs 60% task completion difference could reflect implementation quality as much as CLI vs MCP architecture
+- The post does not distinguish between different LLM hosts. Claude Code's MCP integration has different overhead characteristics than, say, a custom agent using the raw API
+- The CircleCI MCP server recommendation at the end is vendor content (mild but present)
+- Does not address cost (token price per call) — only token count, not dollars
+
+---
+
+## Score
+
+**Score: 3/5** (Moderate — reference as external validation)
+
+Solid framework from a credible source. The inner loop / outer loop vocabulary is worth borrowing. The benchmark data is too thin to cite as evidence but useful as a directional signal. The decision framework would be a meaningful addition to the guide's cost optimization or MCP section — either as inspiration for a new section or as an external reference link.
+
+---
+
+## Challenge
+
+**Challenge**: "The benchmark is methodologically thin and CircleCI is selling their MCP server. This is marketing dressed as engineering. Score should be 2/5."
+
+**Response**: The marketing angle is real but mild — the post's core content (decision framework, inner/outer loop model) stands independently of the CircleCI MCP product pitch at the end. The benchmark is not cited here as evidence; it's noted as a directional signal with the caveat that methodology is undisclosed. The decision framework and vocabulary are the primary value, and those are clean. 3/5 stands. If the guide cites this resource, it should reference the framework, not the benchmark numbers.
+
+---
+
+## Fact-Check
+
+| Claim | Verified | Source |
+|-------|----------|--------|
+| Author: Jacob Schmitt, CircleCI | ✅ | Blog byline |
+| Published 2026-03-11 | ✅ | Blog post date |
+| CLI: 77% task completion, 33% better token efficiency | ⚠️ | Cited in post, no methodology link — treat as directional |
+| MCP: 60% task completion | ⚠️ | Same benchmark — same caveat |
+| 6-question decision framework | ✅ | Read from post directly |
+| CircleCI hybrid model (3 layers) | ✅ | Post section "How CircleCI uses both" |
+
+---
+
+## Decision
+
+**Score: 3/5 — Reference as external validation; borrow the inner loop / outer loop vocabulary.**
+
+**Immediate actions**:
+1. Consider adding "inner loop / outer loop" framing to the guide's section on CLI vs. MCP tradeoffs — it is a cleaner mental model than what the guide currently uses
+2. The 6-question decision framework is a good template; a Claude Code-specific version would be higher value than citing the original (the guide's audience needs Claude Code-specific guidance, not generic agentic framework advice)
+
+**What NOT to do**: do not cite the benchmark numbers (77% vs 60%) without disclosing that the methodology is undisclosed and the test is CircleCI-internal.
+
+**Placement**: footnote or "See also" in `guide/core/` cost optimization section, or in the MCP ecosystem section when discussing when to use MCP vs. CLI patterns.
+
+**Confidence**: High on framework quality. Low on benchmark reliability.
--- a/docs/resource-evaluations/2026-03-17-mcp2cli-token-optimization.md
+++ b/docs/resource-evaluations/2026-03-17-mcp2cli-token-optimization.md
@ -0,0 +1,95 @@
+# Resource Evaluation: mcp2cli (knowsuchagency)
+
+**Date**: 2026-03-17
+**Evaluator**: Claude Sonnet 4.6
+**Resource URL**: https://github.com/knowsuchagency/mcp2cli
+**Resource Type**: Open-source CLI tool (GitHub)
+**Author**: knowsuchagency (Stephan Fitzpatrick)
+**Published**: 2026-03-09
+**Stars**: 1,261 | **License**: MIT | **Language**: Python
+
+---
+
+## Executive Summary
+
+mcp2cli converts MCP servers, OpenAPI specs, and GraphQL schemas into runtime CLI commands, eliminating tool schema injection from LLM prompts. The project claims 96-99% token savings by removing schema overhead, with an additional 40-60% via TOON encoding on array output. Created 8 days ago, it has 1,261 stars and a Claude Code skill integration. The architectural insight is real — MCP tool schema injection is a documented cost driver in agentic workflows — but the tool is too new for production recommendation. There is also a structural mismatch with Claude Code's internal MCP architecture: Claude Code manages MCP connections natively, so mcp2cli's schema-elimination approach doesn't map cleanly onto the standard Claude Code workflow.
+
+---
+
+## Content Summary
+
+- **Core mechanic**: converts MCP server definitions, OpenAPI specs, and GraphQL schemas into runtime CLI tools with zero codegen, calling the underlying server on invocation
+- **Token savings claims**: 96-99% reduction by removing tool schema injection from prompts; 40-60% additional via TOON (Tree-Optimized Output Notation) on array output
+- **Features**: OAuth support, spec caching, secrets management, `bake` mode (batch commands), jq integration for filtering
+- **Claude Code skill**: `npx skills add knowsuchagency/mcp2cli --skill mcp2cli` — installs as a skill for direct use in sessions
+- **Supported sources**: MCP servers (stdio, HTTP/SSE), OpenAPI 2.x/3.x, GraphQL schemas
+- **Contributors**: 3 | **Open issues**: 0 | **Last commit**: 2026-03-17
+
+---
+
+## Gap Analysis vs. Guide
+
+| Area | mcp2cli | Guide coverage |
+|------|---------|----------------|
+| MCP schema overhead documentation | ✅ Addresses directly | ❌ Not documented anywhere |
+| Token cost of MCP tool injection | ✅ Core value prop | ❌ Gap — not mentioned in cost section |
+| CLI vs MCP tradeoff pattern | ✅ Practical tool for this | ⚠️ Mentioned at concept level, no concrete tooling |
+| RTK-style output filtering | ❌ Different mechanism (schema removal, not output filtering) | ✅ RTK covered |
+| Claude Code MCP integration | ⚠️ Structural mismatch (see Risk) | ✅ Covered in mcp-servers-ecosystem.md |
+| OpenAPI/GraphQL → CLI conversion | ✅ | ❌ Not covered |
+
+**Real gap**: the guide does not document MCP tool schema overhead as a cost driver. This is worth adding to the cost optimization or MCP ecosystem sections, independent of whether this specific tool is recommended.
+
+---
+
+## Risk Assessment
+
+**Structural mismatch with Claude Code**: Claude Code manages MCP connections internally via its own runtime. mcp2cli's primary value proposition — replacing MCP tool injection with CLI calls — does not apply to the standard Claude Code workflow where tool schemas are injected by the host. The Claude Code skill (`npx skills add`) is the intended integration path, but it positions mcp2cli as a complementary tool rather than a replacement for native MCP. Users expecting "install mcp2cli, save 96% tokens in Claude Code" will be disappointed. The actual use case is closer to: use mcp2cli in scripts, hooks, or non-Claude Code contexts where you control the tool injection.
+
+**Maturity**: 8 days old. No production track record. 0 open issues could mean the tool is solid or could mean it hasn't been stress-tested yet. The Python dependency stack (typer, httpx, pydantic) is mature, but the integration surface with arbitrary MCP servers is wide.
+
+**Token savings claims**: the 96-99% figure references an external blog post and does not include a controlled benchmark against a defined baseline. TOON encoding savings are plausible for array-heavy output but not independently verified.
+
+---
+
+## Score
+
+**Score: 3/5** (Moderate — Watch list)
+
+Real problem, real approach, credible engineering (MIT, active dev, 1K+ stars in one week). The structural mismatch with Claude Code's architecture and the 8-day maturity are the limiting factors. The architectural insight about schema overhead is worth documenting in the guide even if the tool itself isn't ready for a primary recommendation.
+
+---
+
+## Challenge
+
+**Challenge**: "1,261 stars in 8 days is a recency bubble. The guide has a track record problem with early hype. Score should be 2/5."
+
+**Response**: The concern is valid for production recommendation. However, 3/5 here reflects "watch list + document the insight," not "integrate now." The architectural gap (MCP schema overhead is not mentioned anywhere in the guide) is real and independent of mcp2cli's maturity. If the tool were 2/5, the insight would still be worth documenting. Score stays at 3/5 with explicit maturity caveat.
+
+---
+
+## Fact-Check
+
+| Claim | Verified | Source |
+|-------|----------|--------|
+| 1,261 stars | ✅ | GitHub API — created 2026-03-09, checked 2026-03-17 |
+| MIT license | ✅ | LICENSE file in repo |
+| Claude Code skill integration | ✅ | `npx skills add knowsuchagency/mcp2cli --skill mcp2cli` in README |
+| 96-99% token savings | ⚠️ | Claimed in README, references external blog — not independently verified |
+| TOON encoding | ⚠️ | Described in README, no independent benchmark |
+| 3 contributors, 0 open issues | ✅ | GitHub API |
+| Python, typer, httpx | ✅ | pyproject.toml |
+
+---
+
+## Decision
+
+**Score: 3/5 — Watch list. Document the architectural insight now, revisit the tool recommendation in 3 months.**
+
+**Immediate action (guide)**: Add a note in `guide/ecosystem/mcp-servers-ecosystem.md` (or the cost optimization section of the ultimate guide) documenting MCP tool schema overhead as a token cost driver. This insight exists independently of mcp2cli.
+
+**Deferred action**: If mcp2cli reaches 200+ stars sustained after the initial wave, has 10+ contributors, and has documented real-world usage with Claude Code specifically, revisit for mention in `guide/ecosystem/third-party-tools.md`.
+
+**What NOT to do**: Do not mention mcp2cli as a production tool for Claude Code token savings without clarifying the structural mismatch with Claude Code's native MCP architecture.
+
+**Confidence**: High on architecture analysis. Medium on token savings claims (unverified externally). High on maturity assessment.
--- a/docs/resource-evaluations/2026-03-17-mcporter-mcp-toolkit.md
+++ b/docs/resource-evaluations/2026-03-17-mcporter-mcp-toolkit.md
@ -0,0 +1,99 @@
+# Resource Evaluation: MCPorter (steipete)
+
+**Date**: 2026-03-17
+**Evaluator**: Claude Sonnet 4.6
+**Resource URL**: https://github.com/steipete/mcporter
+**Resource Type**: Open-source TypeScript toolkit (GitHub)
+**Author**: Peter Steinberger (PSPDFKit founder)
+**Stars**: 2,966 | **License**: MIT | **Language**: TypeScript
+**Website**: mcporter.dev
+
+---
+
+## Executive Summary
+
+MCPorter is a TypeScript runtime and CLI toolkit for MCP servers: it calls any MCP server programmatically, generates CLI wrappers, and emits typed TypeScript clients. Peter Steinberger (already referenced in the guide for practitioner insights) built it as a developer companion for testing and integrating MCP servers outside IDE environments. At 2,966 stars and 12+ contributors with a 2-week track record, it is meaningfully more mature than mcp2cli. The tool has genuine utility for power users writing hooks or scripts that need MCP server access without a running Claude Code session, but it is not a Claude Code workflow tool in the primary sense.
+
+---
+
+## Content Summary
+
+- **Three operating modes**:
+  - Runtime calling: call any MCP server tool programmatically from TypeScript/Node
+  - CLI generation (`mcporter generate-cli`): generates shell-callable CLIs from MCP server definitions
+  - TypeScript codegen (`mcporter emit-ts`): generates typed TS clients for MCP servers
+- **Auto-discovery**: reads MCP configs from Claude Desktop, Cursor, Codex, Windsurf, VS Code, OpenCode — detects which servers are configured and connects to them
+- **Transport support**: stdio and HTTP/SSE, unified interface regardless of server transport
+- **Connection pooling**: reuses connections across calls for efficiency
+- **OAuth**: full OAuth2 flow for HTTP-based MCP servers requiring auth
+- **Target use cases per README**: testing MCP servers, CI/CD pipelines needing MCP access, scripts and hooks, TypeScript apps consuming MCP services
+- **Contributors**: 12+ | **Last commit**: 2026-03-03 | **Open issues**: tracked actively
+
+---
+
+## Gap Analysis vs. Guide
+
+| Area | MCPorter | Guide coverage |
+|------|----------|----------------|
+| Testing MCP servers outside Claude Code | ✅ Primary use case | ❌ Not documented |
+| MCP servers in hooks and scripts | ✅ `generate-cli` covers this | ⚠️ Hooks documented, MCP-in-hooks not |
+| Typed TypeScript clients for MCP | ✅ `emit-ts` | ❌ Not covered |
+| Auto-discovery of Claude MCP config | ✅ Reads claude_desktop_config.json | ⚠️ Config file location documented, not programmatic access |
+| Debugging MCP servers during development | ✅ Useful companion | ⚠️ MCP Inspector mentioned, MCPorter not |
+| Connection pooling / transport abstraction | ✅ | ❌ Not covered |
+
+**Real gap**: the guide documents MCP server configuration and usage within Claude Code sessions, but does not cover accessing MCP servers programmatically from scripts, hooks, or external tools. MCPorter fills this gap for TypeScript environments.
+
+---
+
+## Steinberger Context
+
+Peter Steinberger is the founder of PSPDFKit (now Nutrient), a well-known iOS/macOS SDK vendor. He is already cited in the guide for sharing operational insights on Claude Code usage in production (multi-agent workflows, cost management). His building MCPorter is a signal that MCP server access from non-IDE contexts is a real workflow need among practitioners — he would not build and publish this if the use case were marginal. The 12-contributor count and mcporter.dev website suggest this is not a weekend experiment.
+
+---
+
+## Score
+
+**Score: 3/5** (Moderate — mention when covering MCP power-user workflows)
+
+The tool is solid and the author is credible. The limiting factor is that it is a companion/debug tool, not a core Claude Code workflow tool. Most Claude Code users accessing MCP servers through the standard interface will never need MCPorter. The target audience is narrower: developers building MCP servers, writing complex hooks that need MCP access, or integrating Claude Code into CI/CD pipelines.
+
+---
+
+## Challenge
+
+**Challenge**: "The auto-discovery of Claude Desktop config is the most interesting feature for the guide's audience, not the TypeScript codegen. The evaluation undersells the debugging angle."
+
+**Response**: Valid. The debug/testing angle (testing MCP server behavior without a running IDE) is probably the highest-value use case for the guide's audience. A developer building a custom MCP server needs a way to call it and inspect responses without restarting Claude Code every time. MCPorter fills that gap cleanly. The `generate-cli` mode is also directly relevant to hook authors. Integration recommendation updated to lead with these two angles.
+
+---
+
+## Fact-Check
+
+| Claim | Verified | Source |
+|-------|----------|--------|
+| 2,966 stars | ✅ | GitHub API |
+| MIT license | ✅ | LICENSE file |
+| Peter Steinberger / PSPDFKit | ✅ | GitHub profile + mcporter.dev About |
+| 12+ contributors | ✅ | GitHub contributors graph |
+| Auto-discovery: Claude, Cursor, Codex, Windsurf, VS Code, OpenCode | ✅ | README config-discovery section |
+| Last commit 2026-03-03 | ✅ | GitHub |
+| TypeScript, stdio + HTTP/SSE | ✅ | README + source |
+| Connection pooling | ✅ | README features |
+
+---
+
+## Decision
+
+**Score: 3/5 — Mention in third-party-tools.md or mcp-servers-ecosystem.md for MCP power-user workflows.**
+
+**Integration angles** (in order of relevance for the guide's audience):
+1. Testing and debugging MCP servers during development — use MCPorter to call server tools directly without restarting Claude Code
+2. Hook scripts needing MCP server access — `generate-cli` creates shell-callable wrappers from an MCP server definition
+3. TypeScript apps or CI/CD pipelines consuming MCP services — `emit-ts` for typed clients
+
+**Placement**: a callout or "See also" in `guide/ecosystem/mcp-servers-ecosystem.md` under a "Testing and debugging MCP servers" paragraph, or in `guide/ecosystem/third-party-tools.md` under a developer tools subsection.
+
+**When to revisit**: already at 3K stars with established author and active contributors — this is ready for a guide mention. The 3/5 score reflects scope (companion tool, not primary workflow) rather than maturity concerns.
+
+**Confidence**: High. Author credibility verified, claims verified against source, use case is clear.
--- a/examples/memory/icm-session-starter.md
+++ b/examples/memory/icm-session-starter.md
@ -0,0 +1,76 @@
+# ICM Session Starter
+> Paste this at the beginning of any Claude Code session to activate ICM context.
+> Requires ICM installed and configured: `brew tap rtk-ai/tap && brew install icm`
+> then `icm init --mode mcp && icm init --mode hook && icm init --mode skill`
+
+---
+
+# Context — ICM (Infinite Context Memory) active in this session
+
+ICM is installed and configured on this machine. Use it to store and retrieve persistent
+memory across sessions, bypassing context window limits.
+
+## Available MCP tools
+
+The `icm` MCP server is running. You have access to 22 `icm_*` tools for storing,
+recalling, and managing persistent memory.
+
+**Direct CLI** (via Bash if needed):
+
+```bash
+# Store a memory
+icm store --topic "<project-slug>" --content "<fact>" --importance high|medium|low|critical
+
+# Recall by semantic query
+icm recall "<natural language query>"
+
+# Inspect
+icm stats          # count, topics, avg weight
+icm topics         # list all topics
+icm list           # list recent memories
+
+# Manage
+icm forget <id>    # delete by ID
+icm decay          # apply temporal decay
+icm prune          # remove low-weight entries
+```
+
+**Important (v0.5.0 syntax)**:
+- `--importance` is an enum: `critical / high / medium / low` — not a float
+- No `memory` subcommand — use `icm store`, `icm recall` directly
+- Permanent knowledge graph: `icm memoir` (separate layer, no decay)
+
+## Slash commands
+
+- `/recall <query>` — search ICM memory
+- `/remember <content>` — store a memory in ICM
+
+## How memories work
+
+Two layers:
+- **Memories** (episodic): timestamped entries with temporal decay based on importance.
+  `critical` importance never decays. `low` fades over time.
+- **Memoir** (semantic): permanent knowledge graph with typed relations
+  (`depends_on`, `contradicts`, `superseded_by`, `part_of`, and 5 others).
+
+Search is hybrid: BM25 full-text (30%) + vector similarity (70%).
+
+A `PostToolUse` hook runs automatically — every N tool calls, ICM extracts context
+and stores it without any explicit action from you.
+
+## Suggested usage in this session
+
+```bash
+# At session start — recall relevant context
+icm recall "<current feature or topic>"
+
+# When making a key decision
+icm store --topic "<project>" --content "<decision and rationale>" --importance high
+
+# For permanent architectural facts
+icm memoir add-concept -m "<project>" -n "<concept>"
+```
+
+## DB location
+
+`~/Library/Application Support/dev.icm.icm/memories.db`
--- a/guide/cheatsheet.md
+++ b/guide/cheatsheet.md
@ -12,7 +12,7 @@ tags: [cheatsheet, reference]

 **Written with**: Claude (Anthropic)

-**Version**: 3.36.0 | **Last Updated**: February 2026
+**Version**: 3.37.0 | **Last Updated**: March 2026

 ---

@ -564,7 +564,7 @@ Deep analysis     → Use Opus (thinking on by default)

 | Problem | Solution |
 |---------|----------|
-| "Command not found" | Check PATH, reinstall npm global |
+| "Command not found" | Check PATH, reinstall: `curl -fsSL https://claude.ai/install.sh \| sh` |
 | Context too high (>70%) | `/compact` immediately |
 | Slow responses | `/compact` or `/clear` |
 | MCP not working | `claude mcp list`, check config |
@ -639,4 +639,4 @@ Speed: `rg` (~20ms) → Serena (~100ms) → ast-grep (~200ms) → grepai (~500ms

 **Author**: Florian BRUNIAUX | [@Méthode Aristote](https://methode-aristote.fr) | Written with Claude

-*Last updated: February 2026 | Version 3.36.0*
+*Last updated: March 2026 | Version 3.37.0*
--- a/guide/ecosystem/mcp-servers-ecosystem.md
+++ b/guide/ecosystem/mcp-servers-ecosystem.md
@ -10,6 +10,8 @@ tags: [mcp, reference, integration]

 This guide covers validated community MCP servers beyond the official Anthropic servers. All servers listed have been evaluated for production readiness, maintenance activity, and security.

+> **Not sure whether to use an MCP server or a CLI tool?** See the [MCP vs CLI Decision Guide](./mcp-vs-cli.md) for a full breakdown of tradeoffs, a decision matrix, and guidance by situation.
+
 ## Table of Contents

 - [Official vs Community Servers](#official-vs-community-servers)
--- a/guide/ecosystem/mcp-vs-cli.md
+++ b/guide/ecosystem/mcp-vs-cli.md
@ -0,0 +1,184 @@
+---
+title: "MCP vs CLI — Decision Guide"
+description: "When to use MCP servers vs CLI tools in Claude Code workflows. Tradeoffs, decision dimensions, and guidance by situation."
+tags: [mcp, cli, tokens, architecture, decision]
+---
+
+# MCP vs CLI — Decision Guide
+
+**Last updated**: March 2026
+
+> Interactive version with guidance table and practitioner quotes: [cc.bruniaux.com/ecosystem/mcp-vs-cli/](https://cc.bruniaux.com/ecosystem/mcp-vs-cli/)
+
+This page compares two integration patterns for giving Claude Code access to external tools and services: MCP servers and CLI tools. Neither is universally better. The right choice depends on your context — and most real workflows end up using both.
+
+---
+
+## What each approach does
+
+**MCP servers** inject tool schemas into Claude's context at session start. Claude sees a structured list of available tools with parameters, types, and descriptions. It then calls those tools natively, receiving structured responses.
+
+**CLI tools** are shell commands that Claude invokes via Bash. Claude drives them the same way a developer would: constructing command strings, parsing text output. No schema injection at startup. The shell is the interface.
+
+---
+
+## Tradeoffs
+
+### MCP strengths
+
+| Advantage | Detail |
+|-----------|--------|
+| **Structured interface** | Tool schemas guide Claude precisely — fewer hallucinated flags or arguments |
+| **Complex auth** | OAuth, token refresh, secrets rotation handled by the server, not the prompt |
+| **Structured output** | JSON responses are directly parseable by Claude and downstream agents |
+| **Observability** | Remote MCP servers can log every call — essential for enterprise usage tracking and ROI attribution |
+| **Distribution at scale** | Update the server once, all connected clients get the change. No per-machine package management. |
+| **Non-technical users** | Users who never touch a terminal can access tools transparently via MCP connectors |
+| **Weaker models** | A structured schema compensates when the model is less capable of parsing CLI help text |
+
+### CLI strengths
+
+| Advantage | Detail |
+|-----------|--------|
+| **Zero context overhead** | No schema injected at startup — relevant when context budget is tight |
+| **Deterministic actions** | Explicit commands with predictable output are easier to audit and test |
+| **Human + AI use** | The same CLI wrapper works for a developer running it manually and for Claude |
+| **Frontier models** | Claude Opus/Sonnet 4.6 can drive complex CLIs (aws-cli, glab, gh) without a structured schema |
+| **Speed** | No connection setup, no MCP handshake — direct subprocess execution |
+| **Simplicity** | Easier to debug, log, and reason about than a remote server call chain |
+| **Skills encapsulation** | A CLI wrapped in a skill is transparent to the user and keeps the tool logic version-controlled |
+
+### MCP weaknesses
+
+| Weakness | Detail |
+|----------|--------|
+| **Schema token cost** | Every MCP server injects its full tool list into the context window at session start, whether or not those tools are used that session |
+| **Connection overhead** | Session startup takes longer with many MCP servers connected |
+| **Debugging difficulty** | Failures inside an MCP server are harder to trace than a failed shell command |
+| **Maintenance complexity** | Running, updating, and securing remote MCP servers adds infrastructure |
+| **Overkill for simple APIs** | A GitLab MCP that surfaces 20% of glab's functionality is worse than glab itself |
+
+### CLI weaknesses
+
+| Weakness | Detail |
+|----------|--------|
+| **No observability** | Shell commands on a local machine are invisible to ops/management tooling |
+| **Distribution problem** | Keeping CLIs updated across a team requires package management discipline (brew, scoop, etc.) |
+| **Weaker models struggle** | A less capable model may hallucinate flags or misread help text — schemas help |
+| **No multi-agent structure** | CLI output requires parsing; structured MCP responses are more reliable across agent-to-agent handoffs |
+| **Non-tech user barrier** | A non-technical user cannot be expected to have a configured CLI environment |
+
+---
+
+## The four decision dimensions
+
+Before asking "MCP or CLI?", answer these four questions. They rank from most to least constraining.
+
+### 1. Who is the end user?
+
+This is the dominant variable. Everything else is secondary.
+
+- **Non-technical user** (using a chat interface, no terminal) → **MCP or skill-encapsulated CLI**. You cannot expose a raw CLI to a non-dev user. Connectors must be MCP-based or wrapped invisibly in a skill that handles the CLI internally.
+- **Technical user / developer** → continue to question 2.
+
+### 2. Which model is driving the tool?
+
+- **Frontier model** (Claude Opus/Sonnet 4.6) → strong enough to drive complex CLIs directly. A structured MCP schema adds overhead without proportional benefit.
+- **Smaller or local model** (Qwen, Mistral, lighter deployments) → structured MCP schemas compensate for weaker CLI parsing ability. MCP is more reliable here.
+
+### 3. Does your organization need observability?
+
+- **Yes** (enterprise, C-level reporting, compliance, ROI attribution on AI spend) → **MCP Remote server**. Local CLI calls are invisible. A remote MCP server can log every tool invocation, associate it with a user, and feed dashboards. You cannot replicate this with CLIs on local machines.
+- **No** (individual dev, local workflow) → observability is not a constraint. CLI is fine.
+
+### 4. How often does the tool schema change?
+
+- **Stable API** (mature tool, versioned interface) → MCP investment pays off over time.
+- **Rapidly changing** or **thin wrapper** → CLI is cheaper to maintain. A hand-rolled glab wrapper that exposes only the 5 commands you actually use is more durable than a GitLab MCP that duplicates the full API surface.
+
+---
+
+## Guidance by situation
+
+Quick reference — not rules, but directional defaults.
+
+| Situation | Lean toward | Rationale |
+|-----------|-------------|-----------|
+| Non-technical user, chat interface | **MCP / Skill** | CLI is inaccessible; connectors must be invisible |
+| Frontier model (Claude 4.x), developer workflow | **CLI** | Model handles it natively; schemas are overhead |
+| Smaller/local model | **MCP** | Schema guides the model reliably |
+| Enterprise, observability required | **MCP Remote** | Only way to log, attribute, and report on usage |
+| Team distribution (10+ devs) | **MCP** | Central update vs per-machine CLI maintenance |
+| Individual dev, local machine | **CLI or skill** | Simpler, faster, no infrastructure |
+| Deterministic actions (git, CI, deploy) | **CLI** | Explicit commands, predictable output, auditable |
+| Complex auth (OAuth, token refresh) | **MCP** | Server handles auth; CLI would require credential plumbing |
+| Tight context budget / many tools loaded | **CLI** | No schema injection at startup |
+| Agent-to-agent structured output | **MCP** | JSON responses are more reliable than parsed CLI text |
+| Debugging / prototyping a new integration | **CLI** | Easier to inspect, faster to iterate |
+| Browser automation (non-frontier model) | **MCP** | Playwright MCP structures interaction reliably |
+| Browser automation (frontier model, Claude Code) | **CLI + skill** | playwright-cli + skill reported faster and more efficient in practice |
+| GitLab / GitHub access | **CLI** (glab, gh) | Official CLIs are richer than most MCP wrappers |
+| Documentation lookup (Context7) | **MCP** | No CLI equivalent; structured doc retrieval has no shell analog |
+
+---
+
+## The hybrid is the default
+
+Most production workflows don't choose one. They use both, with each covering the layer it handles best.
+
+**A practical example** (from practitioners):
+
+- **Inner layer** (local dev iteration, git, file ops, shell scripts) → CLI, fast, deterministic, no overhead
+- **Outer layer** (CI/CD, shared infrastructure, cross-team services) → MCP Remote, observable, centralized, scalable
+- **Skill layer** (user-facing actions, CLI tools encapsulated for non-tech users) → CLIs wrapped in skills, transparent to the end user
+
+The mistake is applying one answer to both layers. A solo developer building a Claude Code workflow for themselves should mostly use CLIs. A team deploying an AI assistant to non-technical colleagues should mostly use MCP.
+
+---
+
+## Token cost of MCP schemas — what the numbers look like
+
+MCP servers inject their full tool list into the context at session start. This is not free.
+
+A typical MCP server with 10-15 tools injects 500-2,000 tokens per session before any task starts. With 5 MCP servers connected, that is 2,500-10,000 tokens of overhead on every session, whether or not those tools are used.
+
+The practical consequence: if you load 10 MCP servers but only use 2 in a given session, you are paying for 8 servers worth of schema every time. This compounds with long sessions and high-frequency workflows.
+
+**Mitigation strategies:**
+
+- Load MCP servers selectively per project (project-level config vs global config)
+- Use CLI tools for high-frequency operations where schema overhead accumulates
+- Monitor token usage per session to identify which MCP schemas are loaded but unused
+- Consider a CLI wrapper for tools you use frequently in tight loops (compile → test → fix cycles)
+
+---
+
+## Tooling in this space
+
+| Tool | What it does | Status |
+|------|-------------|--------|
+| **RTK** (Rust Token Killer) | Filters CLI output before it reaches Claude's context — reduces response verbosity, not schema overhead | Production-ready, actively maintained |
+| **MCPorter** (steipete) | TypeScript runtime for calling MCP servers from scripts, generating CLI wrappers, and emitting typed TS clients. Useful for testing MCP servers and writing hooks that need MCP access. | 3K stars, MIT, 2+ weeks, ready to use |
+| **mcp2cli** (knowsuchagency) | Converts MCP/OpenAPI/GraphQL to runtime CLI, eliminating schema injection. Claims 96-99% token savings. | 1.2K stars, 8 days old — watch list, not production-ready yet |
+
+Note on mcp2cli: the core claim (eliminate schema injection by converting MCP to CLI) is architecturally valid. But Claude Code manages MCP connections internally, so the token savings don't apply directly to the standard Claude Code workflow. The Claude Code skill integration (`npx skills add knowsuchagency/mcp2cli --skill mcp2cli`) is the practical entry point.
+
+---
+
+## What practitioners say
+
+A few representative perspectives from experienced Claude Code users:
+
+> "I prefer CLI for deterministic actions. For GitLab interactions I use glab (the GitLab MCP is too limited) wrapped in a custom CLI — usable by both humans and AI." — practitioner
+
+> "On Claude Code with frontier models, fewer MCPs is better. I replaced playwright-mcp with playwright-cli + skill — faster and more effective. I still use context7-mcp only because I haven't found a CLI equivalent." — practitioner
+
+> "The CLI vs MCP debate is only happening among devs doing dev things. But there's one fundamental constraint: you cannot propose a CLI solution to a non-technical user who just wants to use their tool simply." — practitioner
+
+> "For enterprise industrialization, observability is non-negotiable. CLI on a local machine is a black box. MCP Remote gives you the logging that C-levels need to attribute investment." — practitioner
+
+> "Frontier models are strong enough to drive a CLI directly. A weaker local model will struggle — that's where MCP schemas earn their overhead." — practitioner
+
+---
+
+*Back to [MCP Servers Ecosystem](./mcp-servers-ecosystem.md) | [Third-Party Tools](./third-party-tools.md) | [Main guide](../ultimate-guide.md)*
--- a/guide/ultimate-guide.md
+++ b/guide/ultimate-guide.md
@ -16,7 +16,7 @@ tags: [guide, reference, workflows, agents, hooks, mcp, security]

 **Last updated**: January 2026

-**Version**: 3.36.0
+**Version**: 3.37.0

 ---

@ -5166,7 +5166,7 @@ The `.claude/` folder is your project's Claude Code directory for memory, settin
 | Personal preferences | `CLAUDE.md` | ❌ Gitignore |
 | Personal permissions | `settings.local.json` | ❌ Gitignore |

-### 3.36.0 Version Control & Backup
+### 3.37.0 Version Control & Backup

 **Problem**: Without version control, losing your Claude Code configuration means hours of manual reconfiguration across agents, skills, hooks, and MCP servers.

@ -11531,27 +11531,44 @@ curl -fsSL https://raw.githubusercontent.com/rtk-ai/icm/main/install.sh | sh
 cargo install --path crates/icm-cli
 ```

-**MCP Config** (auto-configured via `icm init`):
+**Setup** (3 separate modes, not a single interactive command):

 ```bash
-icm init   # interactive setup — detects and configures your editor
+# Step 1: MCP server → auto-injects into ~/.claude.json (and 13 other editors)
+icm init --mode mcp
+
+# Step 2: PostToolUse hook → auto-extracts context every N tool calls
+icm init --mode hook
+
+# Step 3: /recall and /remember slash commands
+icm init --mode skill
 ```

+Restart Claude Code after running all three.
+
 **Usage**:

 ```bash
-# Store episodic memory (auto-decay)
-icm store -t "my-project" -c "Use PostgreSQL for main DB" -i high
+# Store episodic memory (importance = critical|high|medium|low, not a float)
+icm store --topic "my-project" --content "Use PostgreSQL for main DB" --importance high

 # Recall with hybrid search
-icm recall "database choice" --topic "my-project"
+icm recall "database choice"

 # Build permanent knowledge graph
 icm memoir create -n "system-architecture"
 icm memoir add-concept -m "system-architecture" -n "auth-service"
 icm memoir link -m "system-architecture" --from "api-gateway" --to "auth-service" -r depends-on
+
+# Session management
+icm stats      # memory count, topics, avg weight
+icm topics     # list all topics
+icm decay      # apply temporal decay manually
+icm prune      # remove low-weight entries
 ```

+**Onboarding prompt**: a ready-to-use session starter template is available at `examples/memory/icm-session-starter.md`.
+
 **Performance** (1000 ops, 384d embeddings — vendor-reported):

 | Operation | Latency |
@ -23402,4 +23419,4 @@ We'll evaluate and add it to this section if it meets quality criteria.

 **Contributions**: Issues and PRs welcome.

-**Last updated**: January 2026 | **Version**: 3.36.0
+**Last updated**: January 2026 | **Version**: 3.37.0
--- a/machine-readable/reference.yaml
+++ b/machine-readable/reference.yaml
@ -3,8 +3,8 @@
 # Source: guide/ultimate-guide.md
 # Purpose: Condensed index for LLMs to quickly answer user questions about Claude Code

-version: "3.36.0"
-updated: "2026-03-13"
+version: "3.37.0"
+updated: "2026-03-17"

 # ════════════════════════════════════════════════════════════════
 # DEEP DIVE - Line numbers in guide/ultimate-guide.md
@ -1581,7 +1581,7 @@ ecosystem:
      - "Cross-links modified → Update all 4 repos"
    history:
      - date: "2026-01-20"
-        event: "Code Landing sync v3.36.0, 66 templates, cross-links"
+        event: "Code Landing sync v3.37.0, 66 templates, cross-links"
        commit: "5b5ce62"
      - date: "2026-01-20"
        event: "Cowork Landing fix (paths, README, UI badges)"
@ -1593,7 +1593,7 @@ ecosystem:
 onboarding_matrix_meta:
  version: "2.1.0"
  last_updated: "2026-03-09"
-  aligned_with_guide: "3.36.0"
+  aligned_with_guide: "3.37.0"
  changelog:
    - version: "2.1.0"
      date: "2026-03-09"
@ -1624,7 +1624,7 @@ onboarding_matrix:
      core: [rules, sandbox_native_guide, commands]
      time_budget: "5 min"
      topics_max: 3
-      note: "SECURITY FIRST - sandbox before commands (v3.36.0 critical fix)"
+      note: "SECURITY FIRST - sandbox before commands (v3.37.0 critical fix)"

    beginner_15min:
      core: [rules, sandbox_native_guide, workflow, essential_commands]
@ -1713,7 +1713,7 @@ onboarding_matrix:
        - default: agent_validation_checklist
      time_budget: "60 min"
      topics_max: 6
-      note: "Dual-instance pattern for quality workflows (v3.36.0)"
+      note: "Dual-instance pattern for quality workflows (v3.37.0)"

  learn_security:
    intermediate_30min:
@ -1724,7 +1724,7 @@ onboarding_matrix:
        - default: permission_modes
      time_budget: "30 min"
      topics_max: 4
-      note: "NEW goal (v3.36.0) - Security-focused learning path"
+      note: "NEW goal (v3.37.0) - Security-focused learning path"

    power_60min:
      core: [sandbox_native_guide, mcp_secrets_management, security_hardening]
@ -1749,7 +1749,7 @@ onboarding_matrix:
      core: [rules, sandbox_native_guide, workflow, essential_commands, context_management, plan_mode]
      time_budget: "60 min"
      topics_max: 6
-      note: "Security foundation + core workflow (v3.36.0 sandbox added)"
+      note: "Security foundation + core workflow (v3.37.0 sandbox added)"

    intermediate_120min:
      core: [plan_mode, agents, skills, config_hierarchy, git_mcp_guide, hooks, mcp_servers]
--- a/scripts/check-landing-sync.sh
+++ b/scripts/check-landing-sync.sh
@ -195,6 +195,42 @@ else
 fi
 echo ""

+# ===================
+# 7. MCP VS CLI PAGE SYNC
+# ===================
+MCP_GUIDE="$GUIDE_DIR/guide/ecosystem/mcp-vs-cli.md"
+MCP_LANDING="$LANDING_DIR/src/pages/ecosystem/mcp-vs-cli.astro"
+
+echo -e "${BLUE}7. MCP vs CLI page sync${NC}"
+
+if [ ! -f "$MCP_GUIDE" ]; then
+    echo -e "   ${YELLOW}INFO${NC}: guide/ecosystem/mcp-vs-cli.md not found (skip)"
+elif [ ! -f "$MCP_LANDING" ]; then
+    echo -e "   ${RED}MISSING${NC}: landing page src/pages/ecosystem/mcp-vs-cli.astro not found"
+    ISSUES=$((ISSUES + 1))
+else
+    # Count H2 sections in guide
+    GUIDE_H2=$(grep -c '^## ' "$MCP_GUIDE" || true)
+    # Count guidance table rows (lines starting with | followed by content, skip header/separator)
+    GUIDE_TABLE_ROWS=$(grep -cE '^\| [^-]' "$MCP_GUIDE" || true)
+    # Count <tr> rows in landing (approximate — includes header rows)
+    LANDING_TR=$(grep -c '<tr>' "$MCP_LANDING" || true)
+
+    echo "   Guide H2 sections: $GUIDE_H2"
+    echo "   Guide table rows:  $GUIDE_TABLE_ROWS"
+    echo "   Landing <tr> rows: $LANDING_TR"
+
+    # Loose check: if landing has zero <tr>, something is wrong
+    if [ "$LANDING_TR" -lt 5 ]; then
+        echo -e "   ${RED}ERROR${NC}: Landing page has too few table rows — may be out of sync"
+        ISSUES=$((ISSUES + 1))
+    else
+        echo -e "   ${GREEN}OK${NC} (landing page exists, has table content)"
+        echo "   Tip: if you update the guide section, mirror changes in mcp-vs-cli.astro"
+    fi
+fi
+echo ""
+
 # ===================
 # SUMMARY
 # ===================
 @ -1 +1 @@
 .36.0
 .37.0