Skip to main content
Glama

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

  1. Overview

  2. Architecture

  3. Project Structure

  4. Available Tools

  5. Getting Started

  6. Configuration

  7. Running the Server

  8. Testing

  9. Adding New Tool Categories

  10. MCP Client Configuration

  11. Logging

  12. Sample Performance Payload


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 Page

Key design decisions:

Concern

Decision

Transport

stdio – required by the MCP spec for local server ↔ agent communication

Logging

Always stderr – stdout is reserved for the JSON-RPC transport

Tool isolation

Each domain (performance, accessibility …) lives in its own file

No external HTTP library

Node ≥ 18 native fetch – keeps the dependency list minimal

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 cxa_scan_performance


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.js

Available 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

url

string

Fully-qualified URL to scan

region

string

Local

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 fetch and --test runner)

  • Chromium / Puppeteer (installed automatically via npm install)

Install

cd mcp-cxa
npm install

Configure

cp .env.example .env
# Edit .env if needed – no API key required

Configuration

All configuration is read from environment variables (see .env.example):

Variable

Default

Description

CXA_SCAN_TIMEOUT_MS

30000

Page load timeout per profile (ms)

CXA_HEADLESS

true

Set false to watch Chromium during dev

CXA_DEFAULT_REGION

Local

Region label stamped on results

CXA_LOG_LEVEL

info

debug / info / warn / error

No CXA_API_BASE_URL or CXA_API_TOKEN are needed – all scanning is self-contained.


Running the Server

# Production
npm start

# Development (auto-restart on file change – Node ≥ 18.11)
npm run dev

Note: 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:watch

Test coverage by module

Module

Test file

src/config/index.js

tests/config/index.test.js

src/utils/logger.js

tests/utils/logger.test.js

src/utils/formatters.js

tests/utils/formatters.test.js

src/services/performanceService.js

tests/services/performanceService.test.js

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:

  1. Create the service

    src/services/accessibilityService.js

    Export getAccessibilitySummary(projectId) and any other methods.

  2. Create the tool file

    src/tools/accessibilityTool.js

    Export registerAccessibilityTools(server) following the same pattern as performanceTool.js.

  3. Register it in the central registry

    // src/tools/index.js
    const { registerAccessibilityTools } = require('./accessibilityTool');
    // ...
    function registerAllTools(server) {
      registerPerformanceTools(server);
      registerAccessibilityTools(server);   // ← add this line
    }
  4. Add a formatter (optional) in src/utils/formatters.js.

  5. Write tests under tests/services/ and tests/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

/test/reports/getSummaryDetails?projectId=<id>

Fetch latest scan summary

POST

/test/scan/trigger

Trigger a new scan (extend when live)

Available Tools

1 tool
cxa_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe fully-qualified URL of the web page to scan (e.g. https://example.com).
regionNoLabel for the scan region – used as metadata in the report. Defaults to 'Local'.Local

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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. 1 tool updatev1.0.0
    • First observedcxa_scan_performance

TDQS

A4.2/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    B
    maintenance
    MCP server that enables AI agents to perform comprehensive web audits using Google Lighthouse with 13+ tools for performance, accessibility, SEO, and security analysis.
    11
    964 npm
    71
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Core 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.
    4
    9 npm
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    This 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