Combining the Aspire MCP server with the Playwright MCP server turns your AI coding assistant into a full-stack observability and browser-automation co-pilot: Aspire gives the model deep insight into your distributed app, while Playwright lets it drive a real browser and APIs to reproduce and verify behavior end-to-end. Used together from GitHub Copilot or Claude Code, they create a tight loop of “see what’s happening in the system” and “reproduce and fix it in the browser” without ever leaving your editor.

MCP servers in your IDE

Model Context Protocol (MCP) servers expose tools and resources that LLM-based assistants like GitHub Copilot and Claude Code can call programmatically, rather than just guessing from text alone. Aspire 13 ships a built-in MCP server directly in the Aspire dashboard that exposes your running app’s resources, logs, traces, and commands. The official Microsoft Playwright MCP server (@playwright/mcp) exposes a real browser session and API calls as tools. When configured in your IDE, either automatically via aspire agent init or manually through each client’s config file, the assistant can automatically chain these tools to inspect services, run flows in the browser, and reason about what it observes.

Aspire MCP in a nutshell

The Aspire MCP server is a local MCP endpoint built into the Aspire dashboard starting with Aspire 13. It integrates Aspire directly into your AI development ecosystem and lets an AI assistant query resources (state, health, endpoints, commands), stream console logs, inspect structured logs and distributed traces, and execute resource-level commands on your AppHost. All of this is exposed through a set of named tools like list_resources, list_traces, and execute_resource_command. You can also annotate specific resources in your AppHost with ExcludeFromMcp() to hide them from the MCP surface and control exactly what your AI assistant can see.

Playwright MCP in a nutshell

The official Microsoft Playwright MCP server (@playwright/mcp) wraps Playwright so LLMs can drive a real browser and APIs via MCP tools. It allows assistants to navigate to URLs, snapshot the accessibility tree, click elements, type text, take screenshots, run JavaScript, and inspect network traffic across Chromium, Firefox, and WebKit. Because it uses the accessibility tree rather than raw HTML for DOM inspection, the AI gets a compact and accurate view of what is on screen, making selectors reliable even on dynamically rendered pages.

Capabilities side by side

Why Aspire and Playwright belong together

On their own, Aspire answers “what is my distributed app doing right now?” while Playwright answers “what happens when a user or client actually drives this UI or API?”. When combined in Copilot or Claude Code, the assistant can correlate user flows in a real browser with service health, logs, and traces, then act on that knowledge by restarting unhealthy resources or suggesting code fixes. This unifies observability and automation into a single conversational workflow.

Prerequisites

To follow along you will need an Aspire app running with the Aspire dashboard enabled, since the MCP server is hosted by the Aspire dashboard. You will also need Node.js 18 or newer for the Playwright MCP server, plus either VS Code with GitHub Copilot Chat or a Claude client such as Claude Desktop or Claude Code that supports MCP. Finally, ensure your AI client allows you to register custom MCP servers (via JSON config, CLI, or UI), as both Aspire and Playwright rely on that capability.

Installing Aspire MCP with the CLI (recommended)

The recommended path is to let the Aspire CLI detect and configure supported AI assistants for you. From your Aspire project directory, run:

cd path/to/your-aspire-app
aspire agent init

The CLI scans the current workspace for supported agent environments, including VS Code with GitHub Copilot, Claude Code, Cursor, and others, and creates or updates the correct MCP configuration files for each detected tool. This avoids manual URL, transport type, and API key wiring and keeps configuration consistent across your entire team.

Installing Aspire MCP manually

If you want full control or your AI assistant is not yet detected by aspire agent init, you can configure Aspire MCP by hand. Start your Aspire app, open the Aspire dashboard, and click the MCP button in the top-right corner. The dialog shows the MCP endpoint URL, transport type, and the x-mcp-api-key header value you need.

The configuration format differs slightly between clients.

VS Code: create or open .vscode/mcp.json and use the servers key. Use an input variable to keep the API key out of source control:

// .vscode/mcp.json
{
  "servers": {
    "aspire": {
      "type": "http",
      "url": "https://localhost:12345/mcp",
      "headers": {
        "x-mcp-api-key": "${input:aspireMcpApiKey}"
      }
    }
  },
  "inputs": [
    {
      "id": "aspireMcpApiKey",
      "type": "promptString",
      "description": "Aspire MCP API key (from the Aspire dashboard MCP dialog)",
      "password": true
    }
  ]
}

Claude Code / Claude Desktop: the Claude configuration format uses the mcpServers key instead:

// Claude config (e.g. ~/.claude/settings.json)
{
  "mcpServers": {
    "aspire": {
      "type": "http",
      "url": "https://localhost:12345/mcp",
      "headers": {
        "x-mcp-api-key": "your-aspire-mcp-key"
      }
    }
  }
}

Store the x-mcp-api-key value using your assistant’s secure secret mechanism wherever available; never commit it to source control directly.

Handling Aspire MCP HTTPS and HTTP

Aspire secures its MCP endpoint with a self-signed HTTPS certificate by default, but some AI assistants cannot yet call MCP endpoints that use such certificates. As a workaround you can configure just the MCP endpoint to use plain HTTP by adding two environment variables to your launchSettings.json:

{
  "profiles": {
    "https": {
      "commandName": "Project",
      "environmentVariables": {
        "ASPIRE_DASHBOARD_MCP_ENDPOINT_URL": "http://localhost:16036",
        "ASPIRE_ALLOW_UNSECURED_TRANSPORT": "true"
      }
    }
  }
}

If you already launch your Aspire app with an HTTP launch profile you may not need any changes at all. Note that removing transport security from the MCP endpoint means the API key travels in plain text, so keep this strictly to local development.

Installing Playwright MCP for Copilot in VS Code

The quickest way is through the VS Code Extensions gallery. Open the Extensions view (Ctrl+Shift+X) and search for @mcp playwright. Select the Microsoft Playwright MCP server entry and click Install to add it to your user profile. VS Code will detect its tools automatically and make them available in Copilot Chat.

Alternatively, install the package globally and register it via the command line:

npm install -g @playwright/mcp

code --add-mcp "{\"name\":\"playwright\",\"command\":\"npx\",\"args\":[\"-y\",\"@playwright/mcp\"]}"

Or add it manually to .vscode/mcp.json using the servers key:

{
  "servers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp"]
    }
  }
}

Once configured, Copilot Chat can invoke Playwright browser tools whenever your prompt calls for browser or API automation.

Installing Playwright MCP for Claude Desktop

Add the Playwright MCP server to your Claude Desktop configuration JSON using the mcpServers key:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp"]
    }
  }
}

If you prefer to install the package globally first, run npm install -g @playwright/mcp before starting Claude Desktop so the server is available without a network download on first use.

Adding Playwright MCP to Claude Code

From your terminal, run:

claude mcp add --transport stdio playwright npx @playwright/mcp

This registers Playwright MCP as a stdio-based MCP server under the name playwright, which Claude Code can then invoke from within your editor. After that, any Claude Code chat session in that workspace can call Playwright tools when you ask it to drive the browser or test an API.

First prompts with Aspire MCP

The Aspire docs suggest starting with simple observability prompts once your AI assistant is wired to the MCP server. Try prompts like “Are all my resources running?”, “Analyze HTTP request performance for RESOURCE_NAME.”, or “Restart unhealthy resources.” and the assistant will translate these into calls to tools like list_resources, list_traces, and execute_resource_command. Because Aspire MCP exposes resource states, health, endpoints, logs, and traces, the assistant can reason over a structured snapshot of your distributed system rather than just static code.

First prompts with Playwright MCP

Playwright MCP’s tools let an assistant drive a browser and APIs directly. For example, you might say “Open my local checkout page at http://localhost:5000, add an item to the cart, and take a screenshot of the final confirmation.” which will translate into tool calls such as browser_navigate, browser_click, browser_type, and browser_screenshot. The server can also execute arbitrary JavaScript via browser_evaluate and capture network traffic via browser_network_requests, which are crucial for automated API and UI testing.

Example workflow overview

To see how these two MCP servers truly complement each other, consider a realistic workflow: debugging and hardening a checkout flow in a microservices-based Aspire app. The high-level loop is: use Playwright MCP to drive the customer journey in a browser, then use Aspire MCP to inspect which backend services were involved, whether any requests were slow or unhealthy, and what logs/traces were emitted. Finally, you turn the outcome into a reusable, agent-generated regression test that can be re-run via Playwright MCP whenever you change related code.

Step 1: Observe a failing flow

Start a Copilot or Claude Code chat scoped to your Aspire solution and describe the problem, for example: “Users report that checkout sometimes hangs after clicking ‘Place order’ in our web app.” Aspire MCP already knows about your resources and their health. Ask the assistant: “Using Aspire MCP, show me the current health and endpoints of all services involved in checkout, then list recent traces where checkout took more than 2 seconds.” which maps to list_resources and list_traces with appropriate filters. From the response you might discover, for instance, that payment-service is intermittently unhealthy or that the orders-api endpoint is slow under certain conditions.

Step 2: Reproduce the flow in the browser

Next, bring Playwright MCP into the conversation to reproduce the issue from the user’s perspective. In the same chat, say something like: “Use the Playwright MCP server to open the checkout page at the Aspire front-end URL, add a test product, fill fake customer details, and click ‘Place order’. Capture a screenshot if it hangs for more than 5 seconds.” which triggers Playwright tools for navigation, clicks, form fills, and screenshots. Because the Playwright server runs a real browser, you get an authentic reproduction, including DOM state, validation messages, and visible spinners, that you can compare with Aspire’s telemetry.

Step 3: Correlate browser and telemetry

Once the Playwright run has executed, ask the assistant to correlate the browser run with Aspire telemetry. A prompt like “Using Aspire MCP, find traces and structured logs from the time window of the last Playwright run, focusing on the checkout and payment services.” leverages tools such as list_structured_logs, list_traces, and list_trace_structured_logs. This lets the assistant align specific browser events (e.g., clicking ‘Place order’) with specific spans, log entries, and downstream calls in your distributed system.

Step 4: Turn it into a regression test

After reproducing and understanding the issue, fix the code and use the assistant plus Playwright MCP to codify the scenario as a reusable test. For example, prompt: “Generate a Playwright-based regression test that opens the checkout page, completes the flow with fake data, verifies that the final confirmation appears, and fails if a spinner remains visible beyond 3 seconds. Use the Playwright MCP tools and show me the code as well.” which will yield test code and an MCP-invocable flow. You can then ask the assistant to re-run the test via Playwright MCP whenever you push changes, and simultaneously use Aspire MCP to verify that the associated traces and logs look healthy.

Using Aspire tools in tandem

Aspire MCP exposes several tools that pair naturally with browser automation. For example, after a Playwright run, you might ask: “List console logs for the front-end resource and structured logs for the orders API related to the last checkout flow,” which uses list_console_logs and list_structured_logs to surface correlated telemetry. You can also use list_integrations and get_integration_docs to have the assistant pull documentation about specific Aspire hosting integrations when it is recommending configuration or deployment changes based on observed behavior. If you want to hide internal or sensitive resources from the AI’s view, annotate them with ExcludeFromMcp() in your AppHost.

Using Playwright tools in tandem

On the Playwright side, the official Microsoft server provides specialized tools beyond basic navigation. browser_screenshot captures full-page or element-specific screenshots, browser_select_option handles dropdown interactions, browser_evaluate executes arbitrary JavaScript snippets, and browser_network_requests exposes captured network traffic for deeper API inspection. The browser_snapshot tool returns the accessibility tree rather than raw HTML, providing a compact, AI-readable representation that highlights roles, labels, and names, exactly what you need to generate reliable selectors. Together these tools let the assistant validate UI states and capture diagnostic artifacts to go alongside Aspire’s service-level telemetry.

Best practices and caveats

Aspire MCP may truncate large data fields such as long exception stack traces or shorten large telemetry collections by omitting older entries to stay within model limits, so design prompts that request focused slices of data rather than “everything”. Because the MCP endpoint can be secured with a self-signed HTTPS certificate or downgraded to HTTP for compatibility, treat x-mcp-api-key and any unsecured transport settings as sensitive, storing keys via your assistant’s secret mechanism and avoiding non-local endpoints. On the Playwright side, run the MCP server against test or staging environments where full browser automation and API manipulation are safe, and ensure Node.js 18+ is available wherever the MCP server process runs.

Daily workflow ideas

In day-to-day work, you can lean on Aspire MCP whenever you need “inside the cluster” insight: resource lists, live logs, traces, and integration docs, while Playwright MCP handles anything “outside-in” like reproducing flows, validating UI changes, or running smoke tests. For example, before merging a feature branch, you might ask your assistant to “run the primary user journeys in the browser using Playwright MCP and then use Aspire MCP to confirm all resources stayed healthy and no slow traces appeared.” which becomes an automated pre-merge gate you can trigger from chat. Over time, this pairing turns Copilot or Claude Code into a powerful, MCP-driven DevEx layer that understands both your system’s behavior and your users’ experience.

Last modified on 2026-05-07