CXA MCP Server
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@CXA MCP ServerRun a performance scan on https://example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
CXA MCP Server
Model Context Protocol server for CX Assurance – exposes an AI-accessible performance tool that lets any MCP-compatible agent (GitHub Copilot, Claude, Cursor, etc.) run real browser-based performance scans and receive a rich dashboard report.
Table of Contents
Related MCP server: LightScout MCP
Overview
The CXA MCP Server is a self-contained performance scanning engine powered by Puppeteer.
An agent can ask "Run a performance scan on https://example.com" and receive a rich Markdown dashboard covering:
Core Web Vitals – Load time, Speed Index (fixed – never negative), TTFB, FCP, DOM Content Loaded, Transfer Size
Performance grades – A+ through F per Web Vitals thresholds
Visual load bars – ASCII progress bars for quick visual comparison
Omni-channel results – Real load times across 6 browser/device profiles with per-profile grades
Mobile vs Desktop comparison – Average load time delta and % slower
Actionable recommendations – Targeted suggestions based on actual metric values
Scope: Performance only. Accessibility, SEO, and security data are intentionally excluded from this tool. No external API is called – all scanning is done locally with a real Chromium browser.
Architecture
Agent (Copilot / Claude / Cursor …)
│
│ JSON-RPC 2.0 (stdio)
▼
┌─────────────────────────────┐
│ MCP Server (stdio) │
│ src/server.js │
│ │
│ ┌──────────────────────┐ │
│ │ Tool Registry │ │ ← src/tools/index.js
│ │ performanceTool.js │ │ ← src/tools/performanceTool.js
│ └──────────┬───────────┘ │
│ │ │
│ ┌──────────▼───────────┐ │
│ │ Service Layer │ │ ← src/services/performanceService.js
│ └──────────┬───────────┘ │
│ │ orchestrates │
│ ┌──────────▼───────────┐ │
│ │ Scanners │ │ ← loadTimeScanner + performanceScanner only
│ └──────────┬───────────┘ │
│ │ │
│ ┌──────────▼───────────┐ │
│ │ Browser Runner │ │ ← Puppeteer / Chromium
│ └──────────────────────┘ │
└─────────────────────────────┘
│ headless Chromium
▼
Target Web PageKey design decisions:
Concern | Decision |
Transport |
|
Logging | Always |
Tool isolation | Each domain (performance, accessibility …) lives in its own file |
No external HTTP library | Node ≥ 18 native |
Error handling | All tool handlers return structured error text instead of throwing, so the agent always receives a readable response |
Scope | Performance-only – accessibility, SEO, security scanners exist but are not wired into |
Project Structure
mcp-cxa/
├── .env.example # Environment variable template
├── .gitignore
├── package.json
├── README.md # ← you are here
│
├── performance-samples/ # Reference data & API docs
│ ├── performance_result.json
│ └── performance-details.md
│
├── src/
│ ├── server.js # Entry point – bootstraps MCP server
│ ├── config/
│ │ └── index.js # Centralised config (env-driven)
│ ├── tools/
│ │ ├── index.js # Central tool registry
│ │ └── performanceTool.js # Performance MCP tool definitions
│ ├── services/
│ │ └── performanceService.js # Business logic / API calls
│ └── utils/
│ ├── logger.js # Structured stderr logger
│ ├── httpClient.js # fetch wrapper with timeout & error handling
│ └── formatters.js # Raw payload → Markdown report
│
└── tests/
├── config/
│ └── index.test.js
├── services/
│ └── performanceService.test.js
└── utils/
├── formatters.test.js
└── logger.test.jsAvailable Tools
cxa_scan_performance
Runs a real browser-based performance scan for any URL and returns a rich Markdown dashboard.
Parameter | Type | Required | Default | Description |
| string | ✅ | – | Fully-qualified URL to scan |
| string | ❌ |
| Label stamped on the report |
Returns: Rich Markdown performance dashboard including:
Score card with grades (A+–F) for load time, TTFB, FCP
ASCII visual load bars
Omni-channel table (6 profiles: Chrome, Edge, Firefox, Safari, Android Chrome, iOS Safari)
Mobile vs Desktop comparison
Actionable recommendations
Note: Accessibility, SEO, and security are not included in this tool's output.
Getting Started
Prerequisites
Node.js ≥ 18.0.0 (for native
fetchand--testrunner)Chromium / Puppeteer (installed automatically via
npm install)
Install
cd mcp-cxa
npm installConfigure
cp .env.example .env
# Edit .env if needed – no API key requiredConfiguration
All configuration is read from environment variables (see .env.example):
Variable | Default | Description |
|
| Page load timeout per profile (ms) |
|
| Set |
|
| Region label stamped on results |
|
|
|
No
CXA_API_BASE_URLorCXA_API_TOKENare needed – all scanning is self-contained.
Running the Server
# Production
npm start
# Development (auto-restart on file change – Node ≥ 18.11)
npm run devNote: The server communicates over stdio. You should not see any output on stdout; all log lines appear on stderr as newline-delimited JSON.
Testing
Tests use Node's built-in test runner (node:test) – no additional test framework required.
# Run all tests once
npm test
# Run tests in watch mode
npm run test:watchTest coverage by module
Module | Test file |
|
|
|
|
|
|
|
|
The HTTP client and MCP tool wiring are tested indirectly through the service tests (the HTTP client is stubbed so no real network calls are made).
Adding New Tool Categories
The server is designed to grow. To add, say, an Accessibility tool:
Create the service
src/services/accessibilityService.jsExport
getAccessibilitySummary(projectId)and any other methods.Create the tool file
src/tools/accessibilityTool.jsExport
registerAccessibilityTools(server)following the same pattern asperformanceTool.js.Register it in the central registry
// src/tools/index.js const { registerAccessibilityTools } = require('./accessibilityTool'); // ... function registerAllTools(server) { registerPerformanceTools(server); registerAccessibilityTools(server); // ← add this line }Add a formatter (optional) in
src/utils/formatters.js.Write tests under
tests/services/andtests/utils/.
MCP Client Configuration
VS Code (GitHub Copilot)
Add the following to your VS Code settings.json or .vscode/mcp.json:
{
"servers": {
"cxa-mcp": {
"type": "stdio",
"command": "node",
"args": ["${workspaceFolder}/mcp-cxa/src/server.js"],
"env": {
"CXA_LOG_LEVEL": "info"
}
}
}
}Claude Desktop (claude_desktop_config.json)
{
"mcpServers": {
"cxa-mcp": {
"command": "node",
"args": ["/absolute/path/to/mcp-cxa/src/server.js"],
"env": {
"CXA_LOG_LEVEL": "info"
}
}
}
}Logging
All log entries are written to stderr as newline-delimited JSON:
{"timestamp":"2026-03-13T06:27:31.123Z","level":"INFO","message":"CXA MCP Server is running – listening on stdio"}
{"timestamp":"2026-03-13T06:27:32.456Z","level":"INFO","message":"Tool invoked: cxa_scan_performance","meta":{"url":"https://example.com","region":"Local"}}Set CXA_LOG_LEVEL=debug to see every browser navigation event.
Sample Performance Payload
The backend returns a JSON object of the following shape (see performance-samples/performance_result.json):
{
"url": "https://www.sammonsfinancialgroup.com/",
"executionId": "464a1bd3-45c8-4390-a31a-5ef779e81ca1",
"timestamp": "2026-03-13T06:27:31.820822Z",
"browser": "Chrome",
"region": "Virginia",
"speedIndex": "0.02 s",
"uiux": "",
"sustainabilityScore": "",
"accessibility": "",
"seoScore": "",
"security": "",
"omniChannel": [
{ "Browser": "Windows 11 - Chrome", "loadTime": 1229, "version": "125" },
{ "Browser": "Android 14 - Chrome", "loadTime": 2058, "version": "14" }
]
}The formatter converts this into a structured Markdown table report that agents can render or summarise for end users.
API Endpoint Reference
Method | Path | Description |
GET |
| Fetch latest scan summary |
POST |
| Trigger a new scan (extend when live) |
Available Tools
1 toolcxa_scan_performanceA
Performs a CX Assurance performance scan for the given URL. The scan is run entirely by this MCP server using a real Chromium browser. No external API is called. Measures: page load speed, TTFB, First Contentful Paint, DOM Content Loaded, transfer size, and omni-channel load times across 6 browser/device profiles (Chrome, Edge, Firefox, Safari, Android Chrome, iOS Safari). Returns a rich Markdown performance dashboard with visual load bars, grades (A+–F), mobile vs desktop comparison, and actionable recommendations. Scope: Performance metrics only – no accessibility, SEO, or security data.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The fully-qualified URL of the web page to scan (e.g. https://example.com). | |
| region | No | Label for the scan region – used as metadata in the report. Defaults to 'Local'. | Local |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the execution model (real Chromium browser run entirely by this MCP server, no external API), the breadth of the scan (6 browser/device profiles), and the return format (Markdown dashboard with grades and recommendations). It omits scan duration, concurrency/rate behavior, and any auth or reachability requirements, which are the remaining behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is front-loaded with the core action and then layers in measurement list, execution model, output shape, and scope in a logical order. The long metric enumeration and profile list are dense but each clause adds decision-relevant information; the only slight cost is length without a hard need for every listed metric.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description appropriately explains the return value (rich Markdown dashboard with load bars, A+–F grades, mobile vs desktop comparison, recommendations). Combined with the stated scope exclusions and execution model, an agent has enough to invoke and interpret the tool; the unmentioned 'region' parameter and absence of timing/rate expectations are minor residual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the schema, and the baseline is 3. The description references 'the given URL' but adds no syntax, validation, or format detail beyond the schema, and the optional 'region' metadata parameter is not mentioned at all, so there is no meaningful semantic lift.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Performs a CX Assurance performance scan for the given URL') and then enumerates exactly what it measures (TTFB, FCP, DOM Content Loaded, transfer size, 6 device profiles). The closing scope sentence ('Performance metrics only – no accessibility, SEO, or security data') sharply bounds the tool, so an agent knows precisely what it does and does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when the tool applies: it runs a real browser scan server-side with no external API dependency, and it explicitly excludes accessibility, SEO, and security data, which routes the agent away from misusing it for those audits. No siblings exist to compare against, and it does not state prerequisites (e.g. whether the target must be publicly reachable), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
cxa_scan_performance
TDQS
Scored across 1 tool
There is only one tool, so there is no risk of selecting the wrong tool or confusing it with another operation. Its purpose is clearly stated as a performance-only scan.
The single tool name cxa_scan_performance uses a clear snake_case verb_noun pattern consistent with MCP naming conventions. With no other tools, there is no inconsistency to assess.
A single tool feels thin for a server surface, even though the scope is narrowly defined as performance scanning. It borders on under-scoped but is defensible for a very specific, single-purpose scanner.
The tool covers performance measurement across multiple browser/device profiles and returns a rich dashboard, matching the stated performance-only scope. Minor gaps exist around configuration, historical comparison, or export options, but core performance scanning is complete.
Maintenance
Related MCP Connectors
Scan any website or MCP server for agent readiness: 0-100 score, a fix per failing check. Free.
Website performance monitoring: scans, Core Web Vitals, RUM data and alerts.
Core Web Vitals metrics by CMS, CDN, and framework — free remote MCP, no auth.
Scan any website or MCP server for agent-trust-readiness; returns a signed, verifiable scorecard.
Related MCP Servers
- AlicenseBqualityBmaintenanceMCP server that enables AI agents to perform comprehensive web audits using Google Lighthouse with 13+ tools for performance, accessibility, SEO, and security analysis.11964 npm71MIT
- AlicenseAqualityDmaintenanceCore Web Vitals analysis powered by Lighthouse. Four tools: analyze a URL, compare two URLs, check against thresholds, or crawl an entire site. Works with Claude Code, Cursor, Windsurf, and any MCP-compatible AI tool.49 npmMIT
- AlicenseAqualityDmaintenanceEnables AI agents to monitor website performance by scanning sites, retrieving Core Web Vitals, detecting regressions, and receiving AI-powered optimization recommendations.106 npmMIT
- AlicenseNot gradedqualityCmaintenanceThis MCP server integrates Google PageSpeed Insights to analyze website performance, accessibility, best practices, SEO, and PWA on mobile and desktop, returning detailed audits and optimization opportunities.MIT