Modern Angular
WebMCP vs the Angular CLI MCP Server: Runtime Tools vs Dev-Time Help
Two Angular features share the letters MCP and people mix them up. The Angular CLI MCP server is dev-time: it feeds docs and project context to the assistant writing your code. WebMCP is runtime: your shipped app hands typed tools to a browser agent. Same three letters, opposite ends.
Why these get confused
A reader searching for "Angular MCP" lands on two things that both say MCP and both involve an AI agent, so it is fair to assume they are the same feature at different maturity. They are not. They sit at opposite ends of the same app's life.
The Angular CLI MCP server runs while you write code. You start it with ng mcp, and it gives your coding assistant a path to current Angular docs, examples, and workspace context, so the agent stops generating Angular from the wrong year. The consumer is your editor. The blast radius is your dev machine.
WebMCP runs after you ship. Your production app registers typed tools, and an AI agent in the end user's browser calls them by name instead of clicking through the DOM. The consumer is the user's browser agent. The blast radius is your production app. The real axis here is not maturity, it is when the thing runs and who is on the other side of it.
The actual difference
Put them side by side and the confusion dissolves. One helps you write Angular at your desk. The other lets the app you already shipped be called by an agent in the wild. Read the table by the row that matches your actual goal, not by the shared acronym.
| Axis | Angular CLI MCP (dev-time) | WebMCP (runtime) |
|---|---|---|
| When it runs | While you write code, locally | After you ship, in the user's browser |
| Who consumes it | Your editor or coding assistant | The end user's browser AI agent |
| What it exposes | Angular docs, examples, workspace context | Typed tools your app declares with provideExperimentalWebMcpTools |
| Maturity label | Default-available since v21; docs still call it experimental | Experimental; a W3C Community Group draft, not a standard |
| Risk surface | Low: the worst case is a code suggestion you reject in review | High: your shipped app is exposed to an agent in production |
| Blast radius | Your dev machine | Your production app |
| How you start it | ng mcp, plus ng generate ai-config | Register tools, entry point document.modelContext |
Which one you actually want
If your problem is that AI-written Angular comes out stale or off-style, you want the dev-time side. Run ng mcp so the assistant reads current docs and your workspace, and run ng generate ai-config to drop repo rules the assistant follows. The server has been default-available since v21, and the docs still label it experimental, but it runs at dev time, so the worst case is a bad suggestion you reject in review. The full setup is in Angular CLI MCP and AI-Generated Angular Code.
If your problem is that you want an AI agent to drive your shipped app through typed tools rather than synthetic clicks, you want WebMCP. That capability is real and the Angular wiring is clean, but it is experimental: the spec is a Community Group draft, and even in v22 it sits behind the experimental APIs. So you spike it behind a flag on a low-stakes route, not ship it into a payment flow.
The trap is reaching for WebMCP when all you wanted was better autocomplete in your editor, or reaching for the CLI MCP server when you actually need your app to answer an agent at runtime. Match the tool to which end of the app you are standing at: are you writing the code, or is your code being called?
ng mcp
ng generate ai-config --tool agentsReusable artifact
Which MCP do I reach for?
- Goal: better AI-written Angular at your desk → Angular CLI MCP server (
ng mcp) plusng generate ai-config. Default-available since v21, dev-time, low-risk. - Goal: your shipped app callable by a browser agent through typed tools → WebMCP (
provideExperimentalWebMcpTools). Experimental; spike behind a flag. - If the consumer is your editor, it is the dev-time CLI MCP server. If the consumer is the end user's browser agent, it is runtime WebMCP.
- If a wrong move costs you a rejected suggestion, you are on the dev-time side. If it costs you a production incident, you are on the WebMCP side.
- Need both? They compose: use the CLI MCP server to help you write the WebMCP tools, then ship those tools behind a flag.
FAQ
Are WebMCP and the Angular CLI MCP server the same thing?
No. The Angular CLI MCP server is dev-time and feeds docs and workspace context to the assistant writing your code. WebMCP is runtime and lets a browser agent call typed tools your shipped app exposes. Same three letters, opposite ends.
Which one should I use?
If you want better AI-written Angular, use the CLI MCP server (ng mcp) and ng generate ai-config; it has been default-available since v21 and runs at dev time, so a bad suggestion just gets rejected in review. If you want your shipped app callable by a browser agent, use WebMCP, but it is experimental, so spike it behind a flag instead of shipping it into a critical flow.
Is either one stable?
Both still carry the experimental label, so the useful question is the risk, not the label. The CLI MCP server has been default-available since v21, and the docs still call it experimental, but it runs at dev time, so a bad call costs you a rejected suggestion. WebMCP is also experimental, a W3C Community Group draft, not a standard, and Angular still ships it behind the experimental APIs, now in v22 (releases); a bad call there reaches your production app.
Sources checked
- https://angular.dev/ai/mcp
- https://angular.dev/cli/generate/ai-config
- https://next.angular.dev/ai/webmcp
- https://next.angular.dev/api/core/provideExperimentalWebMcpTools
- https://webmachinelearning.github.io/webmcp/
- https://angular.dev/reference/releases
Modern Angular Playbook
This article is one play.
The Modern Angular Playbook collects the diagnostic, the adoption matrix, eleven plays, and the 30-day plan. Free, in English and Portuguese.
You get both PDFs by email, through the Dojo IA list.
André Ramosavailable for remote roles, UTC−3Get in touch →