{"id":4048,"date":"2026-07-27T12:57:03","date_gmt":"2026-07-27T12:57:03","guid":{"rendered":"https:\/\/www.infragistics.com\/blogs\/?p=4048"},"modified":"2026-08-07T11:33:56","modified_gmt":"2026-08-07T11:33:56","slug":"ignite-ui-mcp-testbed","status":"publish","type":"post","link":"https:\/\/www.infragistics.com\/blogs\/ignite-ui-mcp-testbed","title":{"rendered":"Ignite UI MCP Testbed: An Open-Source Bench for Measuring What Your AI Agent&#8217;s Tooling Actually Does"},"content":{"rendered":"<p><!--\nTITLE: Ignite UI MCP Testbed: Measure What Your AI Agent's Tooling Does\nMETA DESCRIPTION: Ignite UI MCP Testbed benchmarks AI coding agents across MCP servers, Agent Skills, and models, comparing matrix results side by side. Free and open source.\nEXCERPT: The Ignite UI MCP Testbed is a free, open-source appliance that runs one shared prompt across a matrix of platforms, models, and tooling variants, then compares the results side by side. It covers Angular, React, Blazor, and Web Components, gates every run with Playwright verification tests, and drives full CI runs from a single JSON config. No account, no license, no breaking changes - clone it and run your first matrix today.\nSLUG: ignite-ui-mcp-testbed-launch\nNOTE: No hero image\/GIF was supplied in source content. Select one (flagship: Matrix view or History grid screenshot) before publish and replace the HERO IMAGE PLACEHOLDER block below.\n--><\/p>\n\n\n<p class=\"wp-block-paragraph\">AI coding agents are only as good as the context you give them. Hand an agent a Model Context Protocol (MCP) server that looks up live component docs, or a set of Agent Skills that spell out your framework&#8217;s conventions, and it <em>should<\/em> write better code. But &#8220;should&#8221; isn&#8217;t a benchmark. Does the Ignite UI Theming MCP server actually reduce hallucinated APIs? Do skills help more on Angular than on React? Is Sonnet worth it over a free hosted model for your particular prompts?<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Until now, answering those questions meant running the agent by hand, over and over, eyeballing the output, and hoping you remembered what you changed between runs. This tool turns that guesswork into a repeatable experiment.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-css-opacity\"\/>\n\n\n\n<h2 id=\"the-core-idea-matrix-executions\" class=\"wp-block-heading\">The core idea: matrix executions<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The heart of the testbed is a simple but powerful loop. You take <strong>one shared prompt<\/strong> and run it across a grid of combinations:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Platforms<\/strong>: Angular, React, Blazor, and Web Components out of the box.<\/li>\n\n\n\n<li><strong>Variants<\/strong>: a specific bundle of tooling &#8211; which MCP servers are enabled, plus a four-way skills choice (none, generated skills, local skills, or both overlaid) &#8211; so you can pit your draft skills directly against the shipped ones.<\/li>\n\n\n\n<li><strong>Models<\/strong>: anything opencode can drive &#8211; Anthropic, OpenAI, a local OpenAI-compatible endpoint (Ollama, LM Studio), or even keyless free hosted models.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Every instance in that grid becomes its own isolated agent run, executed one at a time &#8211; deliberately sequential, so a big matrix stays within your provider&#8217;s rate limits and each run gets the container to itself. The testbed scaffolds a fresh project, hands the agent the prompt, and builds the resulting app.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Then it screenshots every route the agent generated, runs your verification tests against it, and lays every run next to each other so you can see, concretely, what changed.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Want to know whether skills matter? Run &#8220;with skills&#8221; versus &#8220;without&#8221; across all four frameworks and read the difference off a single grid. That&#8217;s the whole pitch: <strong>stop guessing whether your tooling helps, and start measuring it.<\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator has-css-opacity\"\/>\n\n\n\n<h2 id=\"built-on-open-source-isolated-by-design\" class=\"wp-block-heading\">Built on open source, isolated by design<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The testbed drives <a href=\"https:\/\/opencode.ai\" rel=\"noopener\"><strong>opencode<\/strong><\/a>, an open-source AI coding agent, and exercises the Ignite UI AI toolchain through it: two MCP servers (live component docs \/ API lookup and theming queries) plus the Agent Skills the agent loads automatically.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The only thing you need on your machine is <strong>rootless Podman<\/strong>. Everything else &#8211; Node, .NET, the Ignite UI CLIs, opencode, and a headless Chromium &#8211; is baked into a single container image. Every session spins up its own <strong>fresh, ephemeral container<\/strong>, so nothing leaks between runs and every result starts from a clean slate.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Your model API key is handled with the same care: you type it into the wizard, it&#8217;s passed to the agent as an environment variable, and it is <strong>never written to disk<\/strong> inside the container or echoed back to the browser.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Getting started is two commands:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"shell\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">.\/run.sh build      # build the image (once)\n.\/run.sh            # launch a fresh session at http:\/\/localhost:8080\n<\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">On Windows, the equivalent PowerShell scripts (<code>run.ps1<\/code> \/ <code>stop.ps1<\/code>) handle the path and flag differences for you.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-css-opacity\"\/>\n\n\n\n<h2 id=\"the-four-views\" class=\"wp-block-heading\"><strong>The Web Wizard<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The web wizard organizes everything into four modes, which you can use to interactively setup and configure your test run, then fire it up for execution, and finally to view results, inspect execution logs, see test results, and validate the screenshots captured from each generated view.<\/p>\n\n\n\n<h2 id=\"configuration\" class=\"wp-block-heading\">Configuration<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Before you run anything, the Configuration view lets you manage <strong>provider packs<\/strong>: JSON files that teach the testbed how to scaffold and configure a library &#8211; its scaffold and dev-server commands, its MCP servers, and where its skills come from. Ignite UI ships supported out of the box, but packs are how the testbed reaches <em>beyond<\/em> Ignite UI. Drop in a pack and its frameworks show up as new platforms everywhere else in the tool.<\/p>\n\n\n\n<figure class=\"wp-block-gallery alignfull has-nested-images columns-default is-cropped wp-block-gallery-1 is-layout-flex wp-block-gallery-is-layout-flex\">\n<figure class=\"wp-block-image alignfull\"><img decoding=\"async\" src=\"https:\/\/static.infragistics.com\/marketing\/Website\/blogs\/images\/testbed-provider-config-chrome.png\" alt=\"The Configuration view, where provider packs and MCP servers are registered and made available to the Interactive and Matrix runs.\"\/><\/figure>\n<\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">And the configuration file for Angular Material looks like this:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"json\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">{\n  \"name\": \"angular-material\",\n  \"displayName\": \"Angular Material\",\n  \"description\": \"Angular scaffolded by the Angular CLI with @angular\/material installed - the agent does the Material wiring (theme, typography, components).\",\n  \"version\": \"22.0.0\",\n  \"frameworks\": [\n    {\n      \"id\": \"angular-material\",\n      \"label\": \"Angular Material\",\n      \"scaffold\": {\n        \"cmd\": \"npx\",\n        \"argv\": [\"-y\", \"@angular\/cli\", \"new\", \"{{name}}\", \"--defaults\", \"--style\", \"scss\", \"--skip-git\"],\n        \"cwdIsParent\": true\n      },\n      \"install\": [\"@angular\/material\", \"@angular\/cdk\"],\n      \"dev\": {\n        \"cmd\": \"npx\",\n        \"argv\": [\"ng\", \"serve\", \"--host\", \"0.0.0.0\", \"--port\", \"{{port}}\", \"--poll\", \"1500\"]\n      }\n    }\n  ],\n  \"configure\": {\n    \"mcpServers\": [\n      {\n        \"name\": \"angular-cli\",\n        \"command\": \"npx\",\n        \"args\": [\"-y\", \"@angular\/cli\", \"mcp\"],\n        \"class\": \"angular\",\n        \"label\": \"Angular CLI MCP\",\n        \"description\": \"Angular CLI's built-in MCP server - docs, best practices, project queries\"\n      }\n    ]\n  },\n  \"containerDeps\": { \"npmGlobal\": [\"@angular\/cli\"] }\n}\n<\/pre>\n\n\n\n<h2 id=\"interactive\" class=\"wp-block-heading\">Interactive<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The default view scaffolds a single project, wires up your chosen MCPs, skills, and model, and hands you off to a live opencode web session with streaming token and cost stats. This is the mode for exploring: poking at a prompt, watching the agent work, switching models mid-session to feel the difference.<\/p>\n\n\n\n<figure class=\"wp-block-image alignfull\"><img decoding=\"async\" src=\"https:\/\/static.infragistics.com\/marketing\/Website\/blogs\/images\/testbed-interactive-config-chrome.png\" alt=\"The Interactive view, where a single interactive run is configured and executed.\"\/><\/figure>\n\n\n\n<h2 id=\"matrix\" class=\"wp-block-heading\">Matrix<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This is where the comparison happens. You pick your platforms, define your variants, choose a model, and write one prompt. The testbed then runs every combination <strong>headless<\/strong>: scaffold, run the agent, build, screenshot every route, run the verification tests, and drop the results into History. It&#8217;s the fastest way to answer &#8220;with skills vs. without across all four frameworks&#8221; in a single submission.<\/p>\n\n\n\n<figure class=\"wp-block-image alignfull\"><img decoding=\"async\" src=\"https:\/\/static.infragistics.com\/marketing\/Website\/blogs\/images\/testbed-matrix-chrome.png\" alt=\"Configuring a matrix run: one shared prompt across a grid of platforms and tooling variants.\"\/><\/figure>\n\n\n\n<h2 id=\"history\" class=\"wp-block-heading\">History<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Every run, interactive or matrix, lands in a sortable grid showing its configuration, per-stage timings, token and cost stats, screenshots, and logs. Rows expand into full detail, you can rate each run 1-5 stars, and the whole thing exports to Excel. Crucially, History persists in <code>.\/sessions\/history\/<\/code> on the host, so it <strong>survives across containers<\/strong>: your results don&#8217;t vanish when a session ends.<\/p>\n\n\n\n<figure class=\"wp-block-image alignfull\"><img decoding=\"async\" src=\"https:\/\/static.infragistics.com\/marketing\/Website\/blogs\/images\/testbed-matrix-results-chrome.png\" alt=\"The History grid: every run's timings, token\/cost usage, screenshots, and star ratings in one comparable place.\"\/><\/figure>\n\n\n\n<figure class=\"wp-block-image alignfull\"><img decoding=\"async\" src=\"https:\/\/static.infragistics.com\/marketing\/Website\/blogs\/images\/testbed-history-result-chrome.png\" alt=\"Inspecting a matrix run: detailed view of a single combination's results.\"\/><\/figure>\n\n\n\n<figure class=\"wp-block-image alignfull\"><img decoding=\"async\" src=\"https:\/\/static.infragistics.com\/marketing\/Website\/blogs\/images\/testbed-history-result-screenshot1-chrome.png\" alt=\"View screenshots of every instance of a matrix run.\"\/><\/figure>\n\n\n\n<figure class=\"wp-block-image alignfull\"><img decoding=\"async\" src=\"https:\/\/static.infragistics.com\/marketing\/Website\/blogs\/images\/testbed-history-result-screenshot2-chrome.png\" alt=\"View screenshots of every instance of a matrix run.\"\/><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-css-opacity\"\/>\n\n\n\n<h2 id=\"verification-tests-quality-gates-not-vibes\" class=\"wp-block-heading\">Verification tests: quality gates, not vibes<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Screenshots tell you what the agent produced. <strong>Verification tests tell you whether it works.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The testbed runs your own <strong>Playwright<\/strong> end-to-end tests against each generated app as a post-generation quality gate. You author plain specs (no <code>node_modules<\/code>, no config, no <code>package.json<\/code>) and drop them under <code>.\/tests\/<\/code>. The container provides <code>@playwright\/test<\/code> and a headless Chromium, and each spec runs against the served app.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tests are organized as a <strong>shared<\/strong> set that runs for every platform, plus optional <strong>per-framework overlays<\/strong>:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">tests\/\n  shared\/          # runs for every platform\n    smoke.spec.ts\n  angular\/         # runs only for Angular entries (plus shared\/)\n    grid.spec.ts\n  react\/\n  webcomponents\/\n  blazor\/\n<\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">A spec looks exactly like the Playwright you already know:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"typescript\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">import { test, expect } from '@playwright\/test';\n\ntest('home page renders a grid', async ({ page }) => {\n  await page.goto('\/');\n  await expect(page.locator('igc-grid, igx-grid, .igr-grid')).toBeVisible();\n});\n<\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">When a spec fails, that run is marked <code>test-failed<\/code> in History, distinct from a clean <code>success<\/code> or a <code>build-error<\/code>, and the pass\/fail counts show right in the grid. A grouped picker lets you choose exactly which specs run per framework, so you can dial verification up or down per experiment.<\/p>\n\n\n\n<figure class=\"wp-block-image alignfull\"><img decoding=\"async\" src=\"https:\/\/static.infragistics.com\/marketing\/Website\/blogs\/images\/testbed-matrix-test-selection-chrome.png\" alt=\"Verification tests as a quality gate: pick specs per framework and read pass\/fail counts alongside every run.\"\/><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-css-opacity\"\/>\n\n\n\n<h2 id=\"made-for-ci-not-just-the-browser\" class=\"wp-block-heading\">Made for CI, not just the browser<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Everything the Matrix view collects can also live in a JSON config file, so a full matrix can run <strong>without ever opening the UI<\/strong>:<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"shell\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">.\/run.sh --matrix-config .\/matrix.json            # run it\n.\/run.sh --matrix-config .\/matrix.json --validate  # just check the config\n<\/pre>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"json\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">\/\/ matrix.json\n{\n  \"name\": \"grid+chart baseline\",\n  \"platforms\": [\"angular\", \"react\"],\n  \"variants\": [\n    { \"mcps\": [\"igniteui\", \"theming\"], \"skills\": true, \"localSkills\": false },\n    { \"mcps\": [], \"skills\": false, \"localSkills\": false }\n  ],\n  \"model\": \"anthropic\/claude-sonnet-4-5\",\n  \"prompt\": \"Build a dashboard page with a data grid showing sample sales data and a bar chart summarizing it.\",\n  \"apiKeyEnv\": \"ANTHROPIC_API_KEY\",\n  \"selectedTests\": [\"angular::shared\/smoke.spec.ts\", \"react::shared\/smoke.spec.ts\"],\n  \"autoRun\": true,\n  \"exitOnDone\": false\n}\n<\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Progress mirrors to the terminal with per-entry pass\/fail outcomes, so a config-driven run is followable from a log stream. When the matrix settles, two artifacts land on the host: a self-contained <strong><code>report.html<\/code><\/strong> (summary table, stage timings, token\/cost usage, test results, and embedded screenshots, openable straight from the filesystem) and a machine-readable <strong><code>summary.json<\/code><\/strong> that a CI job can read to see <em>which<\/em> combination regressed.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For pipelines, <code>exitOnDone<\/code> gives you meaningful exit codes: <strong>0<\/strong> if every entry succeeded, <strong>2<\/strong> if everything built but some verification tests failed, and <strong>1<\/strong> for anything worse. That&#8217;s enough to gate a merge on &#8220;did the agent, with this tooling, still produce a working app?&#8221;<\/p>\n\n\n\n<hr class=\"wp-block-separator has-css-opacity\"\/>\n\n\n\n<h2 id=\"extend-it-to-your-own-stack\" class=\"wp-block-heading\">Extend it to your own stack<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The testbed ships tuned for Ignite UI, but it isn&#8217;t locked to it. <strong>Provider packs<\/strong> let you register any library (its scaffold commands, its MCP servers, its skills) as a first-class platform. A matrix config can even carry a pack <strong>inline<\/strong>, making a terminal run fully self-contained in a single file.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The repository includes a complete worked example: an <strong>Angular Material<\/strong> provider defined inline, scaffolded with the Angular CLI, with <code>@angular\/material<\/code> and <code>@angular\/cdk<\/code> installed post-scaffold, and then the <em>agent<\/em> is left to do the Material wiring, which is the thing being tested. It runs one prompt with and without the Angular CLI MCP, so you can see the tool&#8217;s effect directly. If it works for Angular Material, it can work for your component library too.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-css-opacity\"\/>\n\n\n\n<h2 id=\"get-started-with-the-ignite-ui-mcp-testbed\" class=\"wp-block-heading\">Get started with the Ignite UI MCP Testbed<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">It&#8217;s <strong>open source and free for everyone<\/strong>. Whether you&#8217;re evaluating whether MCP servers earn their keep, tuning skills for a specific framework, comparing models against your real prompts, or wiring an agent-quality check into CI, it gives you a repeatable, isolated, side-by-side bench to do it on.<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"shell\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">git clone https:\/\/github.com\/IgniteUI\/igniteui-mcp-testbed\ncd igniteui-mcp-testbed\n.\/run.sh build      # build the image (once)\n.\/run.sh            # launch a fresh session at http:\/\/localhost:8080\n<\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Clone the repository, build the image, and run your first matrix. Then let the grid tell you what your tooling is actually worth.<\/p>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button is-style-fill\"><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/github.com\/IgniteUI\/igniteui-mcp-testbed\" rel=\"noopener\">Get Started on GitHub -&gt;<\/a><\/div>\n\n\n\n<div class=\"wp-block-button is-style-outline is-style-outline--2\"><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/github.com\/IgniteUI\/igniteui-mcp-testbed\/blob\/master\/README.md\" rel=\"noopener\">Read the README<\/a><\/div>\n\n\n\n<div class=\"wp-block-button is-style-outline is-style-outline--3\"><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/github.com\/IgniteUI\/igniteui-mcp-testbed\/issues\" rel=\"noopener\">Open an Issue or Discussion<\/a><\/div>\n<\/div>\n\n\n\n<p class=\"wp-block-paragraph\"><em>The Ignite UI MCP Testbed is open source and available now. Contributions, provider packs, and feedback are welcome.<\/em><\/p>\n\n\n\n<script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@type\": \"TechArticle\",\n  \"headline\": \"Ignite UI MCP Testbed: Measure What Your AI Agent's Tooling Does\",\n  \"datePublished\": \"2026-07-16\",\n  \"author\": { \"@type\": \"Person\", \"name\": \"Konstantin Dinev\" },\n  \"publisher\": { \"@type\": \"Organization\", \"name\": \"Infragistics\", \"url\": \"https:\/\/www.infragistics.com\" },\n  \"mentions\": [\n    { \"@type\": \"Thing\", \"name\": \"Ignite UI MCP Testbed\", \"url\": \"https:\/\/github.com\/IgniteUI\/igniteui-mcp-testbed\" },\n    { \"@type\": \"Thing\", \"name\": \"opencode\", \"sameAs\": \"https:\/\/opencode.ai\" },\n    { \"@type\": \"Thing\", \"name\": \"Agent Skills\", \"sameAs\": \"https:\/\/www.infragistics.com\/products\/ignite-ui\/ignite-ui-ai-agent-skills\" },\n    { \"@type\": \"Thing\", \"name\": \"Ignite UI CLI MCP server\", \"sameAs\": \"https:\/\/www.infragistics.com\/ai-assisted-app-development\" },\n    { \"@type\": \"Thing\", \"name\": \"Ignite UI Theming MCP server\", \"sameAs\": \"https:\/\/www.infragistics.com\/ai-assisted-app-development\" },\n    { \"@type\": \"Thing\", \"name\": \"Ignite UI Grid\", \"sameAs\": \"https:\/\/www.infragistics.com\/products\/ignite-ui-angular\/angular\/components\/grid\/grid\" },\n    { \"@type\": \"Thing\", \"name\": \"Angular Material\", \"sameAs\": \"https:\/\/material.angular.dev\" },\n    { \"@type\": \"Thing\", \"name\": \"Playwright\", \"sameAs\": \"https:\/\/playwright.dev\" },\n    { \"@type\": \"Thing\", \"name\": \"Podman\", \"sameAs\": \"https:\/\/podman.io\" }\n  ]\n}\n<\/script>\n\n\n<p><!--\nSTRUCTURED_RELEASE_METADATA\nproduct: Ignite UI MCP Testbed\nversion: 0.1.0\nrelease_date: 2026-07-16\nframework: Angular, React, Blazor, Web Components\npackage_manager: n\/a (Podman container image, no npm\/NuGet package)\ninstall_command: git clone https:\/\/github.com\/IgniteUI\/igniteui-mcp-testbed && .\/run.sh build && .\/run.sh\nchangelog_url: https:\/\/github.com\/IgniteUI\/igniteui-mcp-testbed\/commits\/master\/\ndocs_url: https:\/\/github.com\/IgniteUI\/igniteui-mcp-testbed\/blob\/master\/README.md\nlicense: MIT\nrepo_url: https:\/\/github.com\/IgniteUI\/igniteui-mcp-testbed\nnew_features: [MatrixExecution, VerificationTestsPlaywright, CIModeJSONConfig, ProviderPacks, HistoryGrid]\nbreaking_changes: false\nbreaking_change_summary: n\/a (initial public release)\nmin_framework_version: n\/a (governed by each platform's own scaffold tool: Angular CLI, Vite, .NET CLI)\ntags: [ai-agents, mcp, model-context-protocol, agent-skills, playwright, podman, opencode, developer-tooling, open-source, ignite-ui]\nEND_METADATA\n--><\/p>","protected":false},"excerpt":{"rendered":"<p>The Ignite UI MCP Testbed is a free, open-source end-to-end testing suite that runs one shared prompt across a matrix of supported platforms, AI models, and tooling variants, then lets you compare the results side by side. It currently covers web app generation tests against Angular, React, Blazor, and Web Components. Every run can include scenario-specific Playwright verification tests. No account, no license, no breaking changes &#8211; clone it and run your first test matrix today and evaluate how your AI agent skills and MCP servers perform.<\/p>\n","protected":false},"author":22,"featured_media":4071,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[139,7,8,9,10],"tags":[84,78,148,20,83,144,143,146,147,145],"class_list":["post-4048","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-engineering","category-angular","category-blazor","category-react","category-web-components","tag-ai","tag-ai-agents","tag-ci-cd","tag-ignite-ui","tag-mcp","tag-mcp-testbed","tag-open-source","tag-opencode","tag-playwright","tag-podman"],"_links":{"self":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts\/4048","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/users\/22"}],"replies":[{"embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/comments?post=4048"}],"version-history":[{"count":14,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts\/4048\/revisions"}],"predecessor-version":[{"id":4064,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts\/4048\/revisions\/4064"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/media\/4071"}],"wp:attachment":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/media?parent=4048"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/categories?post=4048"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/tags?post=4048"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}