Strategy: make the MCP surface the primary interface, not a secondary integration

**From a strategy conversation on 2026-09-15, right after shipping the landing page's AI-native pitch (#see 9fec9af). Chris's framing: "we need to build things for a different world, one where AI is ubiquitous, and we need to assume all users are going to be arriving w AI agents in tow. that's going to be our market."**

## The idea

If most users show up with an agent already attached, the MCP surface (`packages/mcp`) stops being a secondary integration bolted onto the real app and becomes the primary way the product gets used — with the web/Android UI serving as the human's window into what their agent already did, not the main entry point.

Concretely, that reframing would mean the build priority order flips: MCP tool coverage and prompt quality (`build_a_course` and friends) have to be complete and load-bearing *first*, ahead of parity UI work, because that's the surface most usage will actually flow through.

## Why now

The landing page just started explicitly pitching "hand it to your own AI" as the primary path rather than a footnote. This issue is the natural follow-up: decide whether that's just marketing framing or something that should actually change how work gets prioritized and staffed across `packages/mcp` vs `packages/web` / `android/`.

## Decisions to make

- **Is this a prioritization shift or a literal architecture shift?** Does anything about the current split (server owns logic, web/Android/MCP are three thin clients) actually need to change, or is this purely about which client gets attention first?
- **What does "MCP-first" mean for feature sequencing going forward?** E.g., should new features (after Courses) ship MCP tools + prompt before or alongside UI, rather than UI-first as most features have shipped so far this cycle?
- **Does this affect how `build_a_course` and future guide prompts get scoped?** If an agent is doing most of the driving, prompt quality is closer to "the product" than any individual screen.

## Reuse

No new capability needed to start — `packages/mcp` already exists and is functionally complete for decks/courses/study. This is a sequencing and prioritization decision, not a build.

Start by reviewing the existing surface in packages/mcp, including build_a_course and the deck, course, and study coverage described in the issue. Compare its role with packages/web and android/, then document whether MCP-first changes feature sequencing, architecture, or both. Done means a clear prioritization and staffing decision for future features and prompt work.

Written by the indexing model from the issue text.