Why Ignite UI AI Tooling Produces Better Results: MCP vs. No-MCP Benchmarks

Abstract

LLMs used as coding assistants have poor recall of specific component APIs, theming mechanisms, and configuration patterns for proprietary UI libraries – and they fail silently. We ran 7 paired benchmark scenarios against Ignite UI for Blazor and Ignite UI for Angular using Claude Sonnet 4.6 in VS Code Copilot agent mode, comparing sessions with the Ignite UI MCP servers and Agent Skills enabled against identical sessions without them. In all three scenarios where the untooled model ignored the library entirely – despite explicit prompts requiring it – tooling raised component compliance from 0/5 to 5/5. In the hardest single-prompt build, it raised feature completion from 71% to 100%. In our most complex full session, it cut corrective credit spend from 45% to 23% of total cost. Developers and architects deciding whether to invest in AI tooling for framework-specific work will find a decision matrix and code comparisons below, and the complete benchmark data in the research paper. The short answer: when correct library-specific implementation matters, MCP should be treated as required infrastructure, not an optional enhancement.

---

Introduction

Ask Claude Sonnet 4.6 to build a Blazor app using Ignite UI for Blazor components. It will say yes. It will generate code. The code will compile. The app will launch. And then you will spend the next 30 minutes discovering that it used _content/IgniteUI.Blazor.Trial/ as the CSS asset path (wrong), set an XAxisLabel property on IgbCategoryChart (does not exist), and never touched Ignite UI components at all for three of the five required UI elements – choosing Chart.js, custom HTML inputs, and a plain <table> instead.

This is not a hallucination in the dramatic sense. The model did not invent facts. It made plausible guesses based on partial training data, produced syntactically valid code, and delivered output that looks done. None of the errors are caught by the compiler. They surface only at runtime or in visual QA.

We call this the confidently wrong problem: a model that cannot distinguish between what it knows and what it is guessing, applied to a domain (specific component library APIs) where the guess rate is very high.

Model Context Protocol (MCP) servers and Agent Skills directly address this failure mode. They inject authoritative, structured library knowledge into the model’s working context at generation time – replacing guesses with facts. This post summarizes the impact of that injection across 7 paired benchmark scenarios run by two Infragistics developers in May 2026. The complete methodology, per-test appendices, and raw metrics are in the companion research paper.

---

Methodology

Setup: Claude Sonnet 4.6 in VS Code GitHub Copilot Chat (agent mode). Across the study, two developers – Georgi Anastasov and Marina Stoyanova – ran paired sessions for the benchmark tasks: once with MCP servers and Agent Skills enabled, and once without. The only variable was AI tooling availability. Test period: May 19-22, 2026.

AI tooling (when enabled): the Ignite UI CLI MCP server (igniteui-cli – documentation, API reference, and scaffolding tools) and the Ignite UI Theming MCP server (igniteui-theming – design tokens and theme configuration), plus the Ignite UI for Blazor Agent Skills and an AGENTS.md instructions file. All are configured with a single command: npx igniteui-cli ai-config. The research paper describes each tool in detail (Section 2.3, “AI Tooling Under Test”).

Library versions under test: Ignite UI for Blazor (IgniteUI.Blazor 25.2.32) and Ignite UI for Angular (21.2.5).

Metrics captured: acceptance checklist completion (N/M required features), Ignite UI component compliance (0-5 scale, rated by the reviewers: 0 = no meaningful Ignite UI adoption, 5 = correct, appropriate use of the required components), context/token usage, wall-clock time, lines of code, and credit consumption per turn (VS Code Copilot’s built-in credit reporting).

What was not measured: throughput under concurrent sessions, performance at scale (10+ page applications), results on models other than Claude Sonnet 4.6.

Test scenarios:

Test	App	Framework	Complexity
1	BravoBoard Mini – base app	Blazor	Medium (3 prompts)
2	BravoBoard Mini – update/extend	Blazor	Medium-High (4 prompts)
3	Service Desk Mini – single prompt	Blazor	High
4	Flight Finder – plain-to-Ignite refactor	Blazor	Medium
5	Travel Request Mini – minimal prompt	Blazor	Low-Medium
6	Hotel App – 3-page Angular app	Angular	High
7	BizDashboard – full Blazor dashboard	Blazor	High

The full experimental design, environment table, and per-test raw data are in the research paper.

---

Benchmarks

Component Compliance

The central metric: did the model actually use Ignite UI components where required?

Test	Scenario	Without MCP	With MCP	Delta
1	BravoBoard base (3 prompts)	0 / 5	5 / 5	+5 pts
2	BravoBoard update (4 prompts)	0 / 5	5 / 5	+5 pts
3	Service Desk Mini	3 / 5	4 / 5	+1 pt
4	Flight Finder refactor	4 / 5	4 / 5	Tie
5	Travel Request (minimal prompt)	0 / 5	5 / 5	+5 pts
6	Hotel App (Angular)	Multiple wrong components + 8 errors	0 errors, all correct	Significant
7	BizDashboard (Blazor)	45% corrective credit spend	23% corrective credit spend	−22 pp waste

Tests 1, 2, and 5 are the most pointed result: despite the prompts explicitly naming Ignite UI and listing required components, the without-MCP model scored 0/5 in all three. It satisfied every functional requirement – grids worked, charts rendered, data persisted – using Chart.js, custom HTML, and plain CSS. The acceptance checklists hit 100%. The library requirement was not met.

Feature Completion (Single-Prompt Scenarios)

When a single prompt had to deliver a complete application without follow-up correction turns:

Test	Without MCP	With MCP	Gap
3 (Service Desk Mini)	27 / 38 – 71%	38 / 38 – 100%	+29 pp
4 (Flight Finder refactor)	26 / 28 – 95%	28 / 28 – 100%	+5 pp
5 (Travel Request minimal)	13 / 13 – 100%	13 / 13 – 100%	Tie*

* Both hit 100% on the functional checklist – but the without-MCP session used zero Ignite UI components (0/5).

In Test 3, the 11 missing features without MCP included: dashboard charts, ticket edit/delete/assign/status-change/detail-view, delete confirmation dialog, toast notifications, active navigation state, and consistent theming. With MCP, all 38 requirements were delivered in a single prompt.

Time, Context, and Code Volume (Summary)

Time savings varied by scenario – and we report the variance rather than the best case. Two of four timed scenarios completed substantially faster with MCP: the Flight Finder refactor (20 vs. 30 min, −33%) and the alternative Service Desk Mini run (15 vs. 33 min, −55%). The primary Service Desk Mini run was only 2 minutes faster, and Travel Request Mini showed no difference.

Context overhead from MCP is real and front-loaded: multi-prompt sessions reached higher peak context with MCP (~330K vs. ~200K tokens in Test 1), while single-prompt and refactor scenarios ended substantially lower (27.8K vs. 83.1K in Test 4) because the MCP session completed more work per prompt and needed no corrective turns.

MCP sessions also generated 9-20% fewer lines of code in four of five measured tests – the exception being the refactor, where the MCP session added more lines because it delivered two features the untooled session missed.

Full per-test tables for time, context, and code volume are in the research paper.

Credit Cost: First Pass vs. True Total

Credits are VS Code Copilot’s unit of consumption, reported per turn in the agent chat footer. The Angular Hotel App (Test 6) shows why first-pass cost is the wrong optimization metric:

Task	Without MCP	With MCP
Scaffold + navigation	42.2 credits	94.0 credits
Accommodation page	83.3 credits	142.8 credits
Booking page	107.2 credits	159.0 credits
Initial pass total	232.7 credits	395.8 credits
Correction turns	~197+ credits (estimated)	0 credits
True total	~430+ credits	~395.8 credits

Without MCP appears 41% cheaper on the first pass. When correction turns are counted, it is 8% more expensive – and delivers inferior output: a wrong navigation component, a runtime content-projection error, and six raw icon-font strings visible to users.

The Blazor BizDashboard session (Test 7) shows the same pattern from a different angle: without MCP, 45% of the ~728 total credits went to correcting avoidable errors (wrong CSS paths, non-existent component properties, CSS margin hacks). With MCP, 23% of ~803 credits went to corrections – the rest of the later turns were spent on runtime verification, Playwright inspection, and final polish. The full turn-by-turn breakdown is in the research paper.

---

Findings

Finding 1: Without MCP, Ignite UI compliance is 0/5 even when explicitly required. In Tests 1, 2, and 5, the prompt named Ignite UI and listed required components. The model produced functionally complete apps at 100% checklist completion – using Chart.js, plain HTML, and custom CSS. The mechanism: the model has partial, outdated knowledge of Ignite UI APIs and rationally avoids committing to specific component configurations when uncertain. It produces the functional outcome (a chart exists) without the required implementation (an IgbCategoryChart with correct configuration).

Finding 2: Single-prompt feature completion drops 29 percentage points without MCP. Test 3’s single-prompt Service Desk Mini scenario delivered 27/38 features without MCP vs. 38/38 with MCP – a 29 pp gap at identical prompt complexity. The mechanism: MCP enables the model to read the Agent Skills and plan the complete architecture before writing any code, eliminating the iterative “I’ll generate what I know, then fill in the rest” approach that leaves the less-familiar library features (theming, charts, dialogs) incomplete.

Finding 3: MCP’s first-pass credit cost overstates its true cost. The without-MCP session for the Angular Hotel App cost 232.7 credits on the initial pass vs. 395.8 for MCP – appearing 41% cheaper. When correction turns are counted (~197 estimated additional credits), the without-MCP total reaches ~430+, making it 8% more expensive overall. The mechanism: MCP front-loads library knowledge into the generation step, eliminating the discover-error-fix cycle that costs the same number of turns but produces no new features.

Finding 4: MCP generates 9-20% fewer lines of code for equivalent or superior output. Across Tests 1, 2, 3, and 5, MCP sessions generated 59-445 fewer lines while matching or exceeding functional output. The mechanism: without MCP, the model generates more custom implementation code to replicate library behavior it cannot correctly invoke (custom toast service, Chart.js wrapper, plain CSS grid). MCP sessions call the library component directly.

Finding 5: With identical application requirements, the only difference that matters is tooling access. In the controlled Service Desk Mini comparison, both sessions received the same feature, validation, theming, and persistence requirements. The only prompt-level difference was that the MCP run was instructed to consult the available Ignite UI MCP servers, Agent Skills, and AGENTS.md before implementation. The result gap is therefore attributable to library-specific guidance, not to differing application requirements.

Finding 6: Context overhead from MCP is front-loaded and amortized differently by scenario. Multi-prompt sessions show higher MCP peak context; single-prompt and refactor scenarios show lower MCP final context. The mechanism: in multi-prompt sessions, MCP tool definitions persist across the entire context window. In single-prompt scenarios, the MCP lookup happens once, generates correct code, and the session ends – while the non-MCP session iterates, compounding context usage with each corrective turn.

---

Decision Matrix

Scenario	Without MCP	With MCP
Strict library compliance required	❌ 0/5 compliance despite explicit prompt requirement	✅ 5/5 compliance
Single-prompt complete app build	❌ 71% feature completion; 11 missing requirements	✅ 100% completion
Refactor: plain code to Ignite UI	⚠️ 95% complete; missing toast + full theme	✅ 100% complete, 10 min faster
Multi-prompt build (3-7 prompts)	⚠️ Functional, but library noncompliant throughout	✅ Compliant; equivalent cost
Minimal prompt / implicit library	❌ Zero library adoption; model builds with plain HTML	✅ Library auto-discovered and applied
Generic prototype, any UI stack acceptable	✅ Functional at lower initial cost	⚠️ Overhead without proportional benefit
Context budget is the sole constraint	✅ Lower peak context in multi-prompt sessions	❌ Higher peak context; plan for extra compaction

The matrix has a clear winner for five of seven scenarios. The two exceptions are “generic prototype with no library requirement” – where neither approach has a meaningful quality advantage – and “context budget constrained,” where MCP’s peak context penalty is a legitimate concern for very long sessions.

---

The Controlled Comparison: Service Desk Mini, With and Without MCP

This is the cleanest controlled comparison in the study. Both sessions were asked to build the same Service Desk Mini Blazor application in a single prompt: the same two pages, the same feature list (38 acceptance criteria), the same validation rules, theming direction, and persistence requirements, with a hard rule to use Ignite UI for Blazor components as the primary UI implementation.

The only prompt-level difference in the MCP run was this instruction:

Before implementing, use the available Ignite UI MCP servers, Ignite UI CLI MCP (igniteui-cli), Ignite UI theming MCP (igniteui-theming), relevant skills, and AGENTS.md instructions to understand the correct Ignite UI for Blazor setup, components, theming, styling, imports, package configuration, and best practices.

Everything else was identical. The measured difference is whether access to MCP servers, Agent Skills, and agent instructions helped the model implement the same task more correctly, completely, and efficiently.

With MCP – 38/38 features, Ignite UI charts, grid, dialogs, and a consistent custom theme, delivered in a single prompt:

Figure 1: The with-MCP result – Ignite UI for Blazor components throughout, consistent theme, all 38 requirements delivered in one prompt.

Without MCP – 27/38 features; charts, dialogs, toasts, and theming missing or replaced with plain HTML and custom CSS:

Figure 2: The without-MCP result – functionally plausible, but 11 requirements missing and zero use of the mandated component library in key areas.

Both applications are public. Inspect the generated code, the commit history, and the full chat log (chat.json) in the repositories:

• service-desk-mini-mcp – the with-MCP result
• service-desk-mini-no-mcp – the without-MCP result

---

Code Examples

The Wrong CSS Path (Test 7 – Without MCP)

The without-MCP model used the Trial package path for CSS assets. This causes the theme to fail silently: no error, styles simply don’t load.

<!-- Without MCP - wrong package name (Trial suffix does not contain production themes) -->
<link rel="stylesheet"
  href="_content/IgniteUI.Blazor.Trial/themes/light/fluent.css" />

<!-- With MCP - correct paths; both are required -->
<link rel="stylesheet"
  href="_content/IgniteUI.Blazor/themes/light/fluent.css" />
<link rel="stylesheet"
  href="_content/IgniteUI.Blazor/themes/grid/light/fluent.css" />

The MCP server retrieved the correct paths from the Ignite UI Blazor documentation at generation time. Without MCP, the model fell back on partial training data that included Trial-package examples.

Non-Existent Component Properties (Test 7 – Without MCP)

Both errors below cause runtime failures, not build failures. The compiler accepts unknown Blazor component parameters; the runtime throws when it encounters them.

<!-- Without MCP - XAxisLabel does not exist on IgbCategoryChart -->
<!-- The chart auto-detects string fields for the X-axis; no property needed -->
<IgbCategoryChart
  XAxisLabel="Month"
  DataSource="@RevenueData"
  ChartType="CategoryChartType.Line" />

<!-- With MCP - correct usage; X-axis is inferred from data field names -->
<IgbCategoryChart
  DataSource="@RevenueData"
  ChartType="CategoryChartType.Line"
  Height="300px" />

<!-- Without MCP - OutlineThickness does not exist on IgbRingSeries -->
<IgbRingSeries
  DataSource="@MarketData"
  OutlineThickness="2" />   <!-- Runtime error -->

<!-- With MCP - correct configuration -->
<IgbDoughnutChart Height="300px">
  <IgbRingSeries
    DataSource="@MarketData"
    LabelMemberPath="Category"
    ValueMemberPath="Value" />
</IgbDoughnutChart>

Content Projection Slot Error (Test 6 – Without MCP)

Missing igxDialogTitle and igxDialogActions slot directives cause an NG0811 content-projection error at runtime. The dialog renders with a blank body.

<!-- Without MCP - Angular CDK Overlay used instead of IgxDialog -->
<!-- Additionally, slot directives missing if IgxDialog is attempted -->
<igx-dialog #roomDialog>
  <h2>{{ selectedRoom?.name }}</h2>        <!-- Not projected: renders outside dialog -->
  <p>{{ selectedRoom?.description }}</p>   <!-- Not projected: theme leaks from parent -->
</igx-dialog>

<!-- With MCP - correct slot directives; zero runtime errors -->
<igx-dialog #roomDialog [isModal]="true" [closeOnEscape]="true">
  <igx-dialog-title>{{ selectedRoom?.name }}</igx-dialog-title>

  <div igxDialogContent>
    <igx-carousel [interval]="0">
      <igx-slide *ngFor="let img of selectedRoom?.images">
        <img [src]="img" [alt]="selectedRoom?.name" />
      </igx-slide>
    </igx-carousel>
    <p>{{ selectedRoom?.description }}</p>
  </div>

  <div igxDialogActions>
    <button igxButton="flat" (click)="roomDialog.close()">Close</button>
    <button igxButton="raised" (click)="navigateToBooking()">Book Now</button>
  </div>
</igx-dialog>

The MCP-guided session also used IgxChip inside IgxChipsArea for amenity tags and IgxCarousel with interval="0" for manual navigation – both correct on the first attempt.

---

Conclusion

Use MCP and Agent Skills for any task that touches a specific UI component library. For tasks where Ignite UI is the implementation requirement – not just a suggestion – MCP is the difference between 0/5 and 5/5 compliance in the scenarios where the untooled model ignores the library, between 71% and 100% feature completion in a single prompt, and between spending 45% of your session budget fixing avoidable errors versus 23%.

The credit premium for MCP on the initial pass is real: 41% more expensive for the Angular Hotel App on the first pass, 10% more for the Blazor BizDashboard. Both premiums disappear when correction turns are counted in the total. The without-MCP path is not cheaper – it charges the correction cost later.

The one scenario where MCP adds cost without proportional return: a generic prototype where the UI stack is genuinely flexible. If any HTML that renders is acceptable, MCP overhead is waste. Once a specific library enters the requirement, MCP is not an optimization – it is the mechanism by which the library requirement is actually met.

The open question this study does not answer: how quickly MCP server content becomes stale relative to library releases, and what happens when the MCP knowledge predates an API change by one major version. A stale MCP server providing outdated component APIs could produce confidently wrong output with the appearance of authority. Pin your MCP servers to release-tagged versions and update them on every library release.

The complete study – full methodology, all benchmark tables, and per-test raw data appendices – is in AI Tooling in Framework-Specific Development: An Empirical Study of MCP and Agent Skills Benefits.

---

Data Availability

• service-desk-mini-mcp – the with-MCP benchmark application (Test 3), including AGENTS.md, Agent Skills, and the full prompt/chat log (chat.json)
• service-desk-mini-no-mcp – the without-MCP benchmark application (Test 3)
• Raw test data and comparison spreadsheets for the remaining scenarios are available from the Infragistics Ignite UI team.

---

Learn More

• AI-Assisted App Development with Ignite UI
• Ignite UI Agent Skills
• React Data Grid

References

[1] “Ignite UI for Blazor – Getting Started,” Infragistics. https://ko.infragistics.com/products/ignite-ui-blazor/blazor/components/general-getting-started

[2] “Ignite UI for Angular – Getting Started,” Infragistics. https://ko.infragistics.com/products/ignite-ui-angular/angular/components/general/getting-started

[3] “Model Context Protocol – Specification,” Anthropic / MCP Community. https://modelcontextprotocol.io/introduction

[4] “GitHub Copilot Agent Mode,” Microsoft, VS Code Documentation. https://code.visualstudio.com/docs/copilot/copilot-agent

[5] “Claude Sonnet 4.6 – Model documentation,” Anthropic. https://docs.anthropic.com/en/docs/about-claude/models

[6] “ASP.NET Core Blazor class libraries and static web assets – _content/ path convention,” Microsoft Docs. https://learn.microsoft.com/en-us/aspnet/core/blazor/components/class-libraries

[7] “service-desk-mini-mcp,” IgniteUI, GitHub, June 2026. https://github.com/IgniteUI/service-desk-mini-mcp

[8] “service-desk-mini-no-mcp,” IgniteUI, GitHub, June 2026. https://github.com/IgniteUI/service-desk-mini-no-mcp

---

Georgi Anastasov, Marina Stoyanova, and Radoslav Mirchev, Infragistics Ignite UI Team. June 2026. All tests conducted in VS Code with GitHub Copilot Chat in agent mode using Claude Sonnet 4.6, May 19-22, 2026.