A primitive is a foundational experience behavior — not a single feature or button. It repeats across many portal surfaces and enables multiple higher-level features. The portal is best viewed as a composition of primitives, not a list of pages.
We want to identify what Azure Portal delivers today that is not yet represented in MCP tools and Azure skills. A feature-by-feature audit is not practical: portal capabilities are extensive and constantly evolving. Instead, use a primitives-based lens: durable, high-value gaps.
- Identify the core experience primitives in Azure Portal
- Assess whether each primitive exists in MCP tools or Azure skills today
- Assess how well the portal actually delivers each primitive (not aspirationally — honestly)
- Prioritize investments based on primitive-level gaps
This keeps the analysis focused on experience coverage instead of feature parity.
The portal continuously evaluates environment state and surfaces guidance without explicit user prompts.
Examples:
- Cost optimization recommendations
- Security posture findings
- Reliability or configuration warnings
This is system-initiated insight, not user-initiated lookup.
Portal delivery:
MCP gap: Partial. Advisor, Defender, and Cost Management all have APIs — MCP tools can query recommendations on demand. But the portal's model is push, not pull: recommendations appear without asking. In MCP, you have to explicitly call "get recommendations." Skills can encode "check Advisor before making changes" but that's a workaround, not a native experience.
The portal encodes relationships between resources and experiences. From a resource, users can navigate directly to:
- Related cost views
- Security findings
- Logs, metrics, policies, and dependencies
This supports a connected mental model instead of isolated tasks.
Portal delivery:
MCP gap: Partial. Resource Graph can express relationships. MCP tools can return related resource IDs. But the low-friction traversal ("click here to see the related thing") doesn't exist — you copy a resource ID, construct a new query, and run it. Skills can encode navigation patterns, but each hop is a manual command.
Before impactful actions, the portal:
- Explains likely consequences
- Provides validation or previews
- Requires explicit confirmation
This reduces execution risk and increases trust.
Portal delivery:
MCP gap: Achievable. Azure CLI already has --what-if for deployments, --dry-run for some operations, and confirmation prompts. MCP tools can implement preview/validate/confirm patterns. Skills can encode "always run what-if before deploying." This primitive translates naturally to CLI/API because it's fundamentally about information before action.
The portal provides durable operational memory through:
- Historical trends
- Time-series charts
- Dashboards and rollups
Insight comes from temporal context, not only point-in-time queries.
Portal delivery: ✅ Mostly delivered. Metrics Explorer, Log Analytics, Application Insights, Activity Log — Azure has strong time-series tooling. Dashboards aggregate views. Workbooks enable sophisticated temporal analysis. However, these tools require configuration and expertise. Out-of-the-box, most resource blades show minimal temporal data. Comparing "before vs. after a change" requires manually setting time ranges and correlating across blades.
MCP gap: Partial. Time-series data is fully queryable via Azure Monitor and Metrics APIs. But the dashboard experience — seeing trends at a glance, correlating multiple metrics visually, spotting anomalies by shape — requires rendering. The data primitive is achievable; the perception primitive is not.
The portal frequently includes:
- Recommended SKUs
- Suggested configurations
- Best-practice defaults
Users can override defaults, but are not required to decide everything from scratch.
Portal delivery: ❌ Weak. Some create wizards suggest SKUs. But defaults are often the cheapest or simplest option, not the recommended one. Creating a storage account defaults to LRS, not the recommended RA-GRS for production. The portal rarely says "for your use case, we recommend X." New users face a wall of choices without enough guidance on which choices matter. Compare to Vercel (picks the right defaults for a framework automatically) or Railway (auto-detects app type and configures accordingly).
MCP gap: Achievable. Skills are purpose-built for this. A skill can encode "for dev workloads, use Standard_D2s_v3" or "always enable diagnostic settings." Portal default values are just encoded domain knowledge — skills carry the same knowledge into MCP. The gap is in surface area (which defaults are encoded), not mechanism.
The portal provides a global search bar, resource browse blades, marketplace discovery, and "All services" navigation. This is about finding things when you have NO starting context — exploring, not traversing known relationships.
Why it's distinct from Contextual Navigation (#2): Contextual Navigation is "from here, go to related thing." Search and Discovery is "I don't know where to start."
Portal delivery:
MCP gap: Hard. MCP tools require you to know what you want. There's no equivalent of typing "postgres" into the portal search bar and seeing resources, marketplace offerings, docs, and recent items all at once. Skills can encode discovery patterns, but the unified, ambient discoverability is missing entirely.
The portal constantly reflects who you are: your tenant, your subscription filter, your RBAC permissions. What you can see and do is shaped by identity. Buttons are grayed out when you lack permissions. Subscription pickers scope everything. Directory switching changes your entire world.
Portal delivery: ✅ Mostly delivered. This is deeply baked into the portal — it's so pervasive it's invisible. RBAC-aware rendering, tenant switching, and subscription filtering all work.
MCP gap: Hard. MCP tools handle auth as a prerequisite (authenticate, then call), but don't surface the IMPLICATIONS of your identity. The portal tells you "you can't do this because you lack Contributor role" — MCP returns a 403. Proactive access-awareness is absent.
The portal has a notification bell, activity log, deployment tracking, and long-running operation polling. When you kick off an 8-minute deployment, the portal shows progress, lets you navigate away, and notifies you on completion or failure.
Why it's distinct from Stateful Views (#4): Stateful views are about historical trends and metrics. Async awareness is about tracking in-flight operations and their outcomes.
Portal delivery: ✅ Mostly delivered. The notification bell, deployment blade, and activity log all work. You can fire-and-navigate.
MCP gap: Partial. Long-running operation APIs exist and polling is possible. But the ambient notification model — a bell icon accumulating status across all operations — has no MCP equivalent. You'd need a separate polling/notification layer.
The portal operates within a persistent scope: tenant → management group → subscription → resource group. Users set subscription filters once and everything respects that scope. They can switch context without restarting their workflow.
Portal delivery: ✅ Delivered. Subscription filters persist. Directory switching works. Scope is session-level.
MCP gap: Hard. MCP tools are stateless — every call needs subscription ID, resource group, etc. There's no session-level scope. Users repeat scope parameters constantly. Skills could encode default scopes, but the portal's fluid scope-switching has no MCP analog.
The ability to roll back, undo, or revert changes after they've been made. This is distinct from Safe Execution Framing (#3) — that's about preventing bad actions; this is about recovering from them.
Portal delivery: ❌ Weak. Resource locks exist but are obscure and rarely set proactively. No "undo" for most operations. No rollback for manual portal edits. ARM deployment history exists but requires template understanding to revert. Compare to Vercel (instant rollback, one click) or Railway/GCP Cloud Run (revision-based rollback).
MCP gap: High opportunity. MCP tools can track state before and after operations, enabling automated rollback. This is an area where MCP could EXCEED the portal experience.
Operating on sets of resources simultaneously — bulk tagging, bulk resize, bulk policy application, fleet-wide configuration changes.
Portal delivery: ❌ Weak. The portal is fundamentally designed around single-resource interactions. Managing dozens of VMs means clicking through each one. Resource Graph Explorer exists but is query-based, not action-based. AWS has bulk actions in the EC2 console; DigitalOcean lets you tag and manage droplets in bulk.
MCP gap: Very high opportunity. MCP tools and CLI are naturally suited to scripted bulk operations. This is where MCP can dramatically outperform the portal.
Showing cost information inline — in resource blades, create wizards, resize dialogs, and management views — rather than requiring navigation to a separate cost tool.
Portal delivery: ❌ Weak. Azure Cost Management exists but is a destination, not ambient context. When you resize a VM, you don't see the cost delta inline. When you browse resources, you don't see their monthly cost. Compare to DigitalOcean (cost on every droplet), Render (cost per service), Railway (spend per project in real-time).
MCP gap: High opportunity. MCP tools can embed cost lookups into every resource operation, which would leapfrog the portal's current cost experience.
Seeing what's happening NOW, as it happens — streaming logs, live metrics, real-time deployment status, immediate feedback on changes.
Why it's distinct from Stateful Views (#4): Stateful views are about historical trends. This is about live, streaming awareness of current state.
Portal delivery:
MCP gap: Medium. MCP tools could stream status updates, but the tool-call pattern is inherently request-response, not streaming.
Starting from an observed problem ("my app is slow", "my deployment failed", "users are getting errors") and being guided toward root cause across resource boundaries.
Why it's a primitive: Users come to the portal in troubleshooting mode constantly. The portal's primitives are organized around resources, but troubleshooting is organized around symptoms.
Portal delivery:
MCP gap: High opportunity. MCP tools can orchestrate cross-resource diagnosis, querying multiple sources and correlating results programmatically. This is an area where MCP could significantly exceed portal capabilities.
Structured comparison of alternatives — which SKU, which region, which service (App Service vs. Container Apps vs. AKS) — with tradeoff visibility for cost, features, constraints, and workload fit.
Portal delivery: ❌ Weak. The pricing calculator is external to the portal. Some create blades list SKU options with brief descriptions. But meaningful side-by-side comparison doesn't exist in the portal. AWS has instance type comparison pages; Azure does not.
MCP gap: Medium. MCP skills can encode comparison logic and tradeoff matrices. This is representable but requires significant domain knowledge encoding.
Translating portal actions into reproducible automation — "I just did this in the GUI, now give me the script/template to do it again."
Portal delivery: ❌ Weak. "Export template" exists but is often incomplete or produces non-functional ARM templates. The Automation blade exists on some resources. But the portal doesn't effectively bridge "I did this" to "here's how to repeat it in code."
MCP gap: Very high opportunity. MCP tools ARE the automation layer. If MCP can record portal-equivalent actions as replayable commands, this becomes a uniquely strong capability.
A human-readable summary of what changed in your environment — when, by whom, and what the impact was. Distinct from audit logs (raw events) and metrics trends (numerical data).
Portal delivery: ❌ Weak. Activity Log captures raw events but is hard to read — it's an audit trail, not a narrative. Change Analysis exists in preview but is limited in coverage and resource type support. Comparing "before vs. after" requires manual correlation.
MCP gap: High opportunity. MCP tools can query Activity Log and summarize changes in natural language, providing change narration that exceeds what the portal offers.
Progressive Disclosure is NOT a peer primitive — it's a presentation strategy that applies across all primitives. It describes HOW information is structured visually:
- Starting with high-level summaries
- Revealing advanced options when needed
- Structuring multi-step flows (create/configure wizards)
Every primitive above can be delivered with progressive disclosure (or without it). Treating it as a separate primitive creates an apples-to-oranges problem: the MCP gap for progressive disclosure is trivially "impossible" because text output can't selectively reveal information. The useful question is: "how does each primitive handle information density in a non-visual context?"
Portal delivery: ✅ Mostly delivered — create wizards generally follow stepped patterns (Basics → Networking → Management → Tags → Review). But quality varies wildly by resource type. The portal doesn't adapt to user expertise level.
| # | Primitive | Portal Delivery | MCP Gap | MCP Opportunity |
|---|---|---|---|---|
| 1 | Proactive Recommendations | Pull, not push | Medium | |
| 2 | Contextual Navigation | Data yes, traversal no | Medium | |
| 3 | Safe Execution Framing | Achievable (what-if, dry-run) | Low — close to solved | |
| 4 | Stateful Views Over Time | ✅ Mostly | Data yes, perception no | Medium |
| 5 | Opinionated Defaults | ❌ Weak | Achievable via skills | Low — close to solved |
| 6 | Search and Discovery | Unified experience missing | High | |
| 7 | Identity and Access Context | ✅ Mostly | Ambient awareness missing | High |
| 8 | Async Operation Awareness | ✅ Mostly | Ambient notification missing | Medium |
| 9 | Scope and Context Switching | ✅ Delivered | Stateless tools | High |
| 10 | Reversibility and Undo | ❌ Weak | State tracking + rollback | Very High |
| 11 | Bulk and Fleet Operations | ❌ Weak | Scripted bulk ops | Very High |
| 12 | Ambient Cost Visibility | ❌ Weak | Inline cost lookups | Very High |
| 13 | Real-Time Feedback | Streaming gap | Medium | |
| 14 | Symptom-First Investigation | Cross-resource diagnosis | Very High | |
| 15 | Decision Support | ❌ Weak | Comparison logic in skills | Medium |
| 16 | GUI-to-Code Bridge | ❌ Weak | Record + replay actions | Very High |
| 17 | Change Narration | ❌ Weak | NL change summaries | Very High |
Cross-cutting: Progressive Disclosure (presentation strategy, not a standalone primitive)
Today, MCP tools are strongest at:
- Discrete actions
- On-demand queries
- Stateless execution
Azure skills can encode:
- Domain knowledge
- Reusable workflows
- Organizational conventions
This framing enables clearer questions:
- Which primitives are missing entirely?
- Which are partially represented or inconsistent?
- Which should be owned by tools vs skills vs UI?
- Where can MCP tools EXCEED the portal? (Primitives 10, 11, 12, 14, 16, 17)
During walkthroughs, Basher annotates which primitives are present or absent at each step. A single wizard step might involve multiple primitives:
### Step 3: Configure Networking
- **Action:** Select virtual network settings
- **Primitives Present:**
- [Opinionated Defaults] Default VNet pre-selected
- [Progressive Disclosure] Advanced networking collapsed
- **Primitives Absent (Expected):**
- [Contextual Navigation] No link to existing VNet/NSG config
- [Ambient Cost Visibility] No cost impact of networking choices shown
- [Decision Support] No comparison of networking optionsEach walkthrough ends with a primitive coverage matrix showing which primitives appeared, which were missing but expected, and which weren't applicable. This data feeds the project-level analysis and the output report.