Modern applications are no longer built with one-size-fits-all requirements.

Some teams are building data-heavy enterprise portals. Others are creating analytics dashboards, file management systems, scheduling platforms, workflow designers, project planning tools, or rich content editing experiences.

While many development teams still need a complete UI component suite, some projects are focused on one specific capability. In those cases, purchasing a broad component suite may not always be the most efficient path.

To give developers more flexibility, Syncfusion is introducing a new set of Standalone UI SDKs with the Essential Studio^® 2026 Volume 2 release.

These focused SDK packages allow teams to choose the UI capabilities their applications need, while continuing to build with the same trusted Syncfusion components, consistent APIs, documentation, performance, and professional support.

What’s new in this release?

Starting with the 2026 Volume 2 release, Syncfusion now offers the following Standalone UI SDKs:

• Grid SDK
• Chart SDK
• Scheduler SDK
• Gantt SDK
• Rich Text Editor SDK
• Diagram SDK
• File Manager SDK

These SDKs are designed to complement the Syncfusion UI Component Suite. You can choose a focused SDK when your application has a specific requirement, or choose the UI Component Suite when your project needs a broader collection of enterprise-ready UI components.

Note: Existing Syncfusion customers are not affected. Current product entitlements remain unchanged, and existing customers will continue to receive the products included with their subscription.

Why Standalone UI SDKs?

Every application has a different center of gravity.

• For a business intelligence application, charts and dashboards may be the core experience.
• For an ERP system, data grids and pivot tables may matter most.
• For a booking platform, scheduling is the priority.
• For a workflow automation tool, diagrams may be essential.

Standalone UI SDKs make it easier to choose a product based on what your application is actually built around.

• Choose a Standalone UI SDK when your application focuses on a specific UI capability.
• Choose the UI Component Suite when your application requires a broader set of components across multiple functional areas.

This gives development teams more control over product selection, licensing, and long-term scalability without changing the Syncfusion development experience.

Meet the new Standalone UI SDKs

Each Standalone UI SDK is built around a focused application scenario and includes the components commonly required for that type of solution.

Explore the 7 New Standalone SDKs

Pick the SDKs you need. Build smarter. Deliver faster.

Grid SDK

Build enterprise-grade data applications using a powerful SDK that includes:

DataGridTreeGridPivot Table

File Manager SDK

Provide a familiar file explorer experience for managing files and folders.

File Manager

Scheduler SDK

Create feature-rich scheduling experiences for appointments, meetings, and resource management.

SchedulerCalendarDatePicker

Diagram SDK

Design interactive diagramming experiences for visualizing complex relationships and processes.

Diagram

Gantt SDK

Build advanced project management applications with an SDK that includes:

Gantt ChartKanban

Rich Text Editor SDK

Deliver powerful content editing experiences with advanced tools for creating and formatting rich content.

Rich Text EditorBlock Editor

Chart SDK

Create interactive data visualization experiences with a comprehensive SDK that includes:

Charts & 3D ChartsCircular ChartsStock ChartSankey DiagramHeatMapTreeMapMapsGuagesSparklineBullet ChartBarcode GeneratorRange SelectorSmile ChartDashboard Layout

Grid SDK

The Grid SDK is designed for applications that need to display, manage, edit, and analyze structured data.

Includes:

• DataGrid
• TreeGrid
• Pivot Table

Ideal for:

ERP systems, CRM platforms, financial applications, inventory management systems, admin portals, reporting interfaces, and data-heavy enterprise applications.

Chart SDK

The Chart SDK is built for dashboards, analytics applications, and interactive data visualization experiences.

Includes:

• 2D and 3D Charts
• Circular Charts
• Stock Chart
• Sankey Diagram
• HeatMap
• TreeMap
• Maps
• Gauges
• Sparkline
• Barcode Generator
• Range Selector
• Smith Chart
• Bullet Chart
• Dashboard Layout

Ideal for:

Business intelligence dashboards, analytics platforms, monitoring systems, financial dashboards, reporting tools, and data visualization applications.

Scheduler SDK

The Scheduler SDK is designed for applications that need calendar, appointment, and resource scheduling capabilities.

Includes:

• Scheduler

Ideal for:

Healthcare appointment systems, booking platforms, workforce management tools, education portals, event management applications, and calendar-based business solutions.

Gantt SDK

The Gantt SDK is designed for project planning, timeline management, and task tracking applications.

Includes:

• Gantt Chart
• Kanban

Ideal for:

Project management systems, agile planning tools, resource management applications, task tracking platforms, and work planning solutions.

Rich Text Editor SDK

The Rich Text Editor SDK helps developers build modern content creation and editing experiences.

Includes:

• Rich Text Editor
• Block Editor

Ideal for:

Content management systems, blogging platforms, documentation tools, knowledge bases, email composition experiences, and collaborative content editing applications.

Diagram SDK

The Diagram SDK helps developers create interactive diagramming, visualization, and workflow design experiences.

Includes:

• Diagram

Ideal for:

Flowcharts, BPMN diagrams, organizational charts, workflow builders, network diagrams, process visualization tools, and visual modeling applications.

File Manager SDK

The File Manager SDK helps developers build secure and intuitive file and folder management experiences.

Includes:

• File Manager

Ideal for:

Document management systems, digital asset management platforms, cloud storage applications, enterprise portals, and internal file operation tools.

Which product should you choose?

Choosing the right product depends on the type of application you are building.

When should you choose the UI Component Suite?

The UI Component Suite continues to be the best choice when your application requires a broad collection of UI components across multiple functional areas. It is ideal for teams building full-featured enterprise applications that need components for data management, visualization, navigation, layouts, forms, editors, calendars, notifications, and more.

The UI Component Suite provides a comprehensive toolkit with consistent APIs, themes, documentation, and professional support across the Syncfusion UI ecosystem.

Note: Starting with the 2026 Volume 2 release, Scheduler, Diagram, Gantt, and Rich Text Editor are available as standalone SDKs and are licensed separately. Existing customers retain their current product entitlements without any changes.

What does this mean for existing customers?

There is no change for existing Syncfusion customers.

If you already have an active Syncfusion subscription, your current product access and entitlements remain unchanged. You will continue to receive the products, updates, and support included with your existing license.

The new Standalone UI SDKs simply provide an additional purchasing option for new customers or teams that want to license a focused set of UI capabilities based on specific project needs.

Support, updates, and product quality

Although the packaging model is expanding, the development experience remains the same.

Each Standalone UI SDK continues to receive:

• Regular product updates
• New feature enhancements
• Performance improvements
• Bug fixes
• Documentation and demos
• Professional support from the Syncfusion team
• Long-term maintenance and enterprise-grade reliability

Whether you choose a Standalone UI SDK or the UI Component Suite, you can continue building with the same Syncfusion quality, performance, and support.

Build with more flexibility

The introduction of Standalone UI SDKs gives developers a more flexible way to choose Syncfusion products.

• If your application is focused on a specific area, such as data management, dashboards, scheduling, file management, workflow design, project planning, or content editing, you can now choose the SDK that best matches your needs.
• If your application needs a wider range of UI components, the UI Component Suite remains available as the complete solution.

With the 2026 Volume 2 release, Syncfusion gives teams more choice in how they build, scale, and license their applications, while continuing to deliver the same trusted components and support developers rely on.

Explore the new Standalone Syncfusion UI SDKs and choose the product that best fits your application needs.

The Model Context Protocol team has promoted its Enterprise-Managed Authorisation extension to stable status, adding a centralised way for organisations to control access to MCP servers through their identity provider. The project states the aim is to replace per-server consent prompts with a zero-touch flow in which users sign in once and then access approved servers without further setup.

When you give instructions to an AI coding agent, it can look like one single thing: you write a prompt, maybe add a project instructions file, and the agent goes to work. In practice, the instructions arrive through several different layers, and the layers behave completely differently from each other. Some load automatically on every single message, some only load when the agent decides to go looking, and some are never loaded as files at all, but fetched live at the exact moment they're needed.

You want to get the right piece of knowledge into the AI coding agent at the right time. If done incorrectly, you could bring in too many tokens of data for every message, for the rest of the session. Or the agent doesn't see it until it has already gone down the wrong path. Both kinds of mistakes lead to the same results: worse outcomes, higher costs, and more iterations of corrections.

In this article, we'll go through the four layers of instructions, what triggers each of them to load, and how to pick the right layer for the right kind of knowledge. The layers exist in Codex, Claude Code, Cursor, Gemini CLI, GitHub Copilot, and most similar tools, even if the file names differ between them.

Understanding the Different Layers

It helps to stop thinking of context as one big bucket, and instead think of it as separate delivery mechanisms:

Every mechanism you'll recognize from these tools falls into one of these buckets. Once you can place a piece of knowledge in the right bucket, deciding where it belongs stops being guesswork.

Always-Loaded Instructions

This is the layer most people already know: AGENTS.md, the open format used by Codex, GitHub Copilot, and many other tools, CLAUDE.md in Claude Code, and GEMINI.md in Gemini CLI. These files are read automatically at the start of every session, before the agent does anything else.

If your repository already has an AGENTS.md, the CLAUDE.md file can simply contain the text @AGENTS.md to automatically import it, so you don't have to maintain two copies.

The automatic loading is exactly what makes this layer expensive. A ten-line instruction file costs you ten lines, once. A three-hundred-line instruction file costs you three hundred lines on every single message of the session, even when the current task needs none of it. There is no opt-out and no "only when relevant" for this layer.

This is why keeping this layer short matters so much. Put the things here that the agent genuinely can't figure out on its own: the exact test command, the package manager, the files it must never touch, and the safety rules that apply every time. Almost everything else can live in one of the cheaper layers below.

This is also a good layer to keep instructions on where the agent can look for more information when needed, for on-demand reads or progressive disclosure. For example, stating the path where documentation files are located, where to read previous ADRs, code style guidelines or similar, so the agent doesn't have to scan multiple directories for it and waste context.

On-Demand Reads

README.md, type definitions, existing tests, the component you tell the agent to "follow the pattern of". None of this loads automatically. The agent has to decide to read the file, spend a tool call doing it, and the content then stays in the context for the rest of the session (or until it gets compacted away).

When used well, this is a good deal. You don't pay for anything that isn't relevant to the current task, and the files can carry far more detail than you would ever want in an always-loaded file. The trade-off is that the agent has to make the right call about what to read.

Point the agent to the right file, and you get one cheap, targeted read. Leave it vague, and the agent might read five files to find the one that mattered, or miss it completely.

It's worth noting that some tools can scope instructions to a part of the repository, like .claude/rules/-files with paths: in their frontmatter, Copilot's .instructions.md files with applyTo globs, or nested AGENTS.md files deeper down in the folder structure. These sit right between always-loaded and on-demand: they don't load for every session, but they load automatically as soon as the agent touches a matching file. This is a useful middle ground for conventions that only matter in one part of a codebase, for example, in a monorepo.

Progressive Disclosure

This is the layer that's easiest to underestimate, and the one that makes the other layers scale.

Skills and plugins are the clearest example. The agent doesn't load the full instructions of every skill up front, since that would defeat the whole point. What it always loads is a short index: a name and a one-line description for each available skill. The full content is only pulled into the context when a skill is actually invoked. The agent knows that the capability exists, without having paid for reading all of it, until it's actually needed.

Anthropic's post about Agent Skills calls this principle progressive disclosure, and it's a good name for the whole layer.

MCP tools show why this layer matters, because they traditionally haven't used it. When you connect an MCP server, the client typically loads every tool's name, description, and full parameter schema up front, straight into the always-loaded layer. This is why adding too many MCP servers is a well-known problem: Anthropic measured a typical five MCP-server setup at around 55,000 tokens of tool definitions, before the agent has even done any work.

The fix is moving the definitions into this layer. With deferred tool definitions, supported by both Anthropic's and OpenAI's platforms, only an index of names stays loaded, and a full schema only arrives when that specific tool is searched for or used. Claude Code and Codex both made this the default in mid-2026, but with fallbacks to up-front loading for older models and providers, so it's still worth checking how your tool of choice handles it.

You can build the same pattern yourself, with nothing more than Markdown files. Keep a short index in an always-loaded file, like AGENTS.md, where each line describes a subject and points to the file holding the details. The pointer instructions mentioned in the always-loaded layer are exactly this: the index costs one line per subject on every message, while a linked file only enters the context when a task actually needs it. These file pointers can be used recursively through folders and files.

Claude Code's auto memory is a built-in example of the pattern. The agent writes down its own learnings in topic files and maintains a MEMORY.md file as a concise index of what's stored where. The index is loaded at the start of every session, while the topic files are only read on demand, when something in the index matches the task at hand.

Anything that is occasionally useful, expensive to load, and possible to identify with a short label is a candidate for this layer. This is the argument for moving long, situational workflows out of AGENTS.md and into skills: a one-line pointer costs almost nothing, and the full content only loads when it's actually relevant.

Live Lookups

The last layer isn't really context in the usual sense. It's a request-response cycle in the middle of a task: nothing is preloaded, a lookup goes out when it's needed, and only the answer comes back. Anthropic's article about context engineering calls this strategy just-in-time context: the agent holds lightweight references, like file paths and URLs, and fetches the actual data at runtime.

The most common form isn't MCP servers or web fetches, it's plain CLI commands. git log and git diff answer history questions without a single file being read into the context. The gh CLI turns pull requests, issues, and CI runs into one-line lookups. A jq filter returns the one field the agent asked about, instead of the whole JSON file. The shape of the command decides the shape, and the size, of the answer, which is what makes the terminal such a strong context tool for agents.

The same mechanism covers MCP calls to a database, documentation lookups, and web fetches. The context is not filled up until the moment of use, and the answer is current, even when the underlying data has changed since yesterday. Asking a documentation tool for the signature of one specific function costs a fraction of pasting in an entire API reference. The catch is that live lookups only work well when they're specific. A vague query returns a vague and bloated answer, and you're back to the same problem as pasting in a whole file.

A Concrete Example

Let's take one concrete instruction, straight from the AGENTS.md of this website: "run pnpm run format after code changes". Where it belongs depends completely on how often it's needed:

• If it applies to every change in the repository, it belongs in AGENTS.md/CLAUDE.md. It's short, it's universal, and the always-loaded cost is worth it.
• If it only applies to one part of the repository, with its own formatting rules, it belongs in a path-scoped rule or a nested instruction file, not in the root file.
• If it's one step of a larger, occasional workflow, like a release checklist, it belongs in a skill that only loads when that workflow runs.
• If the right command depends on what was changed, it's not really a standing instruction at all. It's something the agent should look up in package.json on demand, instead of something you hardcode anywhere.

The same fact, four possible homes, and four very different costs depending on which one you pick.

Picking the Right Layer

There is no right or wrong when it comes to picking a layer, but asking three questions will settle most cases:

• How often is it needed? Knowledge that's needed on every message belongs in the always-loaded layer, if you can keep it short. Knowledge that's needed occasionally belongs in a layer that only loads when it's relevant.
• Is it durable, or about the current task? Durable conventions belong in files. Current-task specifics belong in the prompt, or in a scratch file the agent reads once.
• Would a lookup be cheaper than a preload? If the agent can find the answer itself with one targeted read or one query, that's usually cheaper than a standing instruction, and it stays correct when the underlying thing changes.

These questions won't give a universally right answer, but they're a good check of your instincts before you add one more paragraph to a file that will reload on every message for the rest of the project's life.

More Than a Cost Problem

It's tempting to treat all of this purely as cost optimization, but the quality effect is at least as important.

A short, focused always-loaded layer keeps the agent's attention on the few rules that apply every time, which makes it follow them more reliably. This effect is real enough that Claude Code's documentation recommends keeping instruction files under 200 lines, since longer files reduce how reliably the instructions get followed.

The other layers contribute in the same direction. Well-placed pointers and indexes let the agent start from the right assumptions and go straight to the relevant files, so its effort goes into the actual task. The first attempt is more often the right one, and the follow-up corrections become fewer. Overloading or starving the layers produces the reverse, in both quality and cost.

Getting the layering right improves quality and cost at the same time, because both depend on the same thing: the right information arriving at the right time, in the right shape.

Summary

Instructions to an AI coding agent don't travel through one single pipe. They arrive as always-loaded files, on-demand reads, progressively disclosed indexes, and live lookups, where each layer has a different trigger and a different cost.

The skill worth building is not writing a longer AGENTS.md. It's recognizing which layer a piece of knowledge actually belongs in, and trusting the other layers to do their job. Keep the root file short, move the occasional workflows into skills, and let the agent look up the rest.

A new model drops with lower per-token pricing and better benchmarks. You switch. A week later someone asks why the agent is burning 12x more tokens on the same task while producing worse output.

We ran 150 agent tasks across 15 scenarios on two models, Claude Sonnet 4.6 and Claude Sonnet 5, using GitHub Copilot Chat in VS Code on Windows. The scenarios covered two types of work: architecture and design tasks grounded in Microsoft Learn documentation, and SharePoint Framework project upgrades. Sonnet 5 is the newer model with 33% lower per-token pricing across every token category. The assumption we wanted to test: newer and cheaper means better. What we found was more complicated.

Cheaper tokens, higher bills

Sonnet 5 is cheaper per token across the board. Here’s how the rate cards compare:

In such a comparison, Sonnet 5 wins every line. But rate cards don’t determine your bill: token consumption does, and Sonnet 5 consumes substantially more tokens.

On architecture tasks (12 scenarios, 60 runs per model), Sonnet 5 used 12x more tokens at the median. One scenario saw a single run consume 47x the typical volume. On code upgrades (3 scenarios, 15 runs per model), the gap hit 10x. A 33% per-token discount doesn’t survive that kind of increase.

What this costs you in dollars depends on the task. On code upgrades, Sonnet 5 cost $2.01 per run versus $0.55 for Sonnet 4.6, making the “cheaper” model 3.7x more expensive. On architecture tasks, the story flipped: Sonnet 5 averaged $0.47 per run versus $0.54, making it 12% cheaper where the token increase was moderate enough for the discount to win out. You won’t know which direction your workload goes until you measure it.

Quality didn’t improve either

The newer model might cost more or might cost less, depending on the task. Does it at least produce better output? On architecture work, based on our evals, no.

Both models completed the task at the same rate, 75% on our Select gate (did the agent attempt the right task at all?). Where they differed was output quality. On the 9 scenarios where both produced usable output, Sonnet 4.6 scored 90% on our Idiomatic dimension (does the output follow established patterns and conventions?) versus 78% for Sonnet 5. The older model outperformed or matched quality in 8 of 9 scenarios.

One scenario, designing an IoT analytics architecture, showed the gap most clearly. Both models completed the task every time, but Sonnet 4.6 passed Idiomatic checks in 4 out of 5 runs. Sonnet 5 managed 1. Same prompt, measurably worse output.

More tokens and worse quality on the majority of scenarios. The “upgrade” went in the wrong direction.

When the upgrade actually matters

Code upgrade tasks reversed the picture. We tested three SharePoint Framework (SPFx) project upgrade scenarios, including the gulp-to-Heft migration and the legacy-to-flat ESLint config migration. Sonnet 4.6 passed the Select gate in 60% of runs. Sonnet 5 passed 100%.

The starkest example was upgrading from SPFx v1.21.1 to v1.22.0. Sonnet 4.6 failed all 5 runs, consistently adopting version 1.22.1 from Microsoft Learn documentation instead of the user-requested 1.22.0. Sonnet 5 followed the instruction precisely every time. When the task requires the agent to follow a specific instruction over what it finds in its context, the newer model was more reliable.

Sonnet 5 also showed a willingness to dig deeper. One run consumed 69 million tokens and met 21 out of 30 evaluation criteria by performing extensive web fetching and discovering undocumented migration steps. Sonnet 4.6 never attempted that depth. The thing is though, that you can’t count on this. 4 out of 5 runs in each scenario didn’t reach that depth either. The breakthrough run is real but not reproducible.

The real ceiling is content, not the model

Both models hit the same quality ceiling on code upgrades. Configuration correctness was 0% across all SPFx scenarios for both models. Neither model completed the structural toolchain migration, from gulp to Heft or from legacy ESLint to flat config.

Migration guides typically cover dependency bumps and API surface changes. Structural shifts like switching build systems or config formats involve steps that aren’t documented in one place. In our SPFx scenarios, we identified seven specific file and configuration changes that neither model could discover on its own: build tool flags, package manifest restructuring, file deletions, config format migrations. All concrete, all enumerable, all absent from the documentation.

Neither model can discover what isn’t documented. Spending more on a newer model doesn’t fix a content gap.

This reinforces what we’ve observed across every engagement we’ve run. The agent can only use what it can find. When the grounding content is incomplete, the model version doesn’t matter. We covered this in the AX stack, and the pattern keeps showing up.

Variance as a cost risk

Token consumption wasn’t just higher on Sonnet 5. It was also unpredictable.

Sonnet 4.6 runs clustered tightly, most between 14K and 45K tokens for straightforward architecture tasks. Budgeting is easy when your runs are consistent.

Sonnet 5 runs were all over the map. On that same IoT analytics scenario, one run consumed 6.6 million tokens while another consumed 16,000. Same scenario, same prompt. A single outlier run can cost more than an entire batch of Sonnet 4.6 runs, which makes your costs unpredictable at any scale.

Both models had high variance on complex tasks. Sonnet 4.6’s outliers were occasional though. Sonnet 5’s were the norm.

What we measured and how

We ran two benchmarks through our evaluation platform: 12 Azure architecture scenarios (120 runs) and 3 SharePoint Framework upgrade scenarios (30 runs). Five runs per model per scenario, 150 total.

Each run was evaluated against binary criteria organized into a Select gate and quality dimensions, scored by an LLM judge calibrated for consistency. Costs were computed from actual per-turn token data, priced against GitHub Copilot’s published rates.

Here’s the full picture:

What this means for you

A model upgrade is a hypothesis, that newer means better for your specific tasks and your specific content. Ethan Mollick describes AI capabilities as a jagged frontier: the boundary between what AI can and can’t do is uneven, and tasks that seem equally difficult end up on different sides of it. Model upgrades are jagged in the same way. Sonnet 5 jumped from 60% to 100% task completion on code upgrades while architecture quality dropped from 90% to 78%. You won’t know which side of the frontier your workload falls on until you measure it.

If you’re a platform team evaluating whether to recommend a newer model, or an enterprise team deciding which model to provision, start with your workload. On routine architecture and design work with well-documented domains, the older model delivered equal or better quality at comparable cost. On tasks requiring precise instruction following, the newer model had a genuine edge.

The workload mix determines which model is the better default. If you’re running at scale, token variance matters too: the older model’s tight clustering makes budgeting predictable, while the newer model can swing from 16K to 6.6 million tokens on the same prompt.

But before you spend time evaluating model versions at all, check whether the agent has the information it needs to do the job. We’ve seen agent extensions produce more lift per dollar than model upgrades, because they fix the information gap that both models share. If your documentation has holes, no model switch closes them. Measure first, upgrade second.

The post Not all model upgrades are upgrades appeared first on Microsoft for Developers.

UI generation and background coding agents are two of the "AI" tools that really changed my way of working. Together, they close a gap that's been annoying me for a while: the coding agent still needs someone to describe what the UI should look like, and that someone is usually me, typing a wall of text into an issue and hoping for the best.

Google Stitch generates UI screens (HTML/CSS, Tailwind, Flutter, SwiftUI, whatever…) from a prompt or a sketch. The GitHub Copilot coding agent picks up an issue and produces a pull request in the background, without you sitting in the editor. In this post we look at how to connect the two through MCP, so the coding agent stops guessing at layout, spacing and colors, and starts reading an actual design spec.

Here's how to wire it up, and where it still needs a human in the loop.

My first approach: screenshots in the issue body

My first attempt was to design something in Stitch, paste a screenshot into a GitHub issue, and assign it to Copilot. It kind of works. The coding agent can look at the image, but it's reconstructing layout, colors and spacing from pixels, not from data. You'll get something that looks close, then spend your review cycle nudging padding and hex codes back into alignment. That's not the coding agent's fault — it's just working with less information than it needs.

The right approach: give the agent the design data, not a picture of it

Stitch doesn't just produce a picture. Alongside the generated screens it exposes the underlying HTML, design tokens and a design.md file describing the whole design system — colors, typography, spacing, component patterns. If the coding agent can pull that structured data itself, it stops guessing.

That's what the Stitch MCP server is for. Point the coding agent at it, and instead of an issue that says "make it look like the attached screenshot," you get an issue that says "build the dashboard screen from the Stitch project, screen ID X" — and the agent fetches the real spec.

Step 1: Design the screens in Stitch

Nothing unusual here — describe the flow in Stitch the way you normally would.

Stitch can generate several connected screens in one pass and keeps them visually consistent. Note the project ID and screen IDs — you'll reference them later.

Step 2: Register the Stitch MCP server on the repository

The coding agent runs headless in the cloud, and it doesn't support remote MCP servers that use OAuth. So skip the gcloud auth login dance for this scenario and use Stitch's official remote MCP server with an API key instead — it's a plain HTTP header, not an OAuth flow, and the cloud agent handles that fine.

Generate a key: in Stitch, open your profile menu → Stitch Settings → API Keys → Create Key.

Store it as a repository secret prefixed with COPILOT_MCP_ (this prefix is required for the coding agent to pick it up): go to Settings → Secrets and variables → Actions, add COPILOT_MCP_STITCH_API_KEY.

Then in the repository: Settings → Copilot → MCP servers, and add:

json

{
  "mcpServers": {
    "stitch": {
      "type": "http",
      "url": "https://stitch.googleapis.com/mcp",
      "headers": {
        "X-Goog-Api-Key": "$COPILOT_MCP_STITCH_API_KEY"
      },
      "tools": ["*"]
    }
  }
}

Save it. This same MCP configuration is also shared with Copilot code review, so your reviewer agent gets access to the same design context.

A couple of things worth knowing before you rely on this:

• The coding agent only supports MCP tools, not resources or prompts, so anything the Stitch server exposes as a resource won't show up.
• By default the agent doesn't get write-access MCP tools. Stitch's tools here are all reads (fetch screens, fetch code, fetch design tokens), so that's not a problem — but double-check the tool list if you add other design-related MCP servers later.

Step 3: Write the issue against the design, not around it

With the MCP server registered, an issue can now point straight at the Stitch project instead of re-explaining the design in prose:

Implement the dashboard screen from Stitch project 7-minutes fitness trainer, screen dashboard. Use the Stitch MCP tools to fetch the HTML and design tokens, then build it as a React + Tailwind component under src/components/Dashboard. Match spacing and color tokens exactly. Existing repo conventions apply — see CONTRIBUTING.md.

Assign it to Copilot. The agent fetches the screen HTML and design tokens through the MCP tools, translates that into your actual stack, and opens a draft pull request. Because the GitHub MCP server is also available by default, it can cross-reference the issue and push commits as it goes, same as any other coding agent task.

Step 4: Review like you would any other PR

The generated code won't be pixel-perfect — code generation from a design spec still isn't deterministic, and you'll see small deviations in spacing or font-weight here and there. Treat the Stitch screen as the source of truth and the PR as a first draft, not a final one. If your repo has the Playwright MCP server enabled (it's on by default alongside GitHub's), you can ask the agent to take a screenshot of the rendered component and compare it against the Stitch export as part of the same task — closes the loop without you doing it manually.

Wrapping up

The interesting part isn't that AI can generate a screen or that AI can write a pull request — both have been true for a while. It's that MCP lets the coding agent read the actual design data instead of a description of it, which is the difference between "close enough" and "matches the spec."

More information

• Stitch: stitch.withgoogle.com
• Stitch MCP setup docs: stitch.withgoogle.com/docs/mcp/setup
• GitHub Docs - Configure MCP servers for your repository: docs.github.com
• GitHub Docs - MCP and Copilot coding agent: docs.github.com