DEV Community: Kavin Arvind Ragavan

Build Your First GitHub Copilot Custom Agent: A Practical LoadRunner Example

Kavin Arvind Ragavan — Thu, 24 Sep 2026 04:51:35 +0000

Creating Custom Agents in GitHub Copilot

A good Copilot conversation can solve a one-off problem. A custom agent turns that conversation into a repeatable engineering capability: a named persona with a defined job, a controlled tool surface, and domain knowledge that can be versioned with the repository.

This post is a practical guide to building one. It uses a LoadRunner Agent as the running example, but the design applies equally well to agents for test automation, incident response, documentation, code review, or platform operations.

The goal is not to create a longer system prompt. The goal is to create a small, inspectable workflow that your team can select from Copilot Chat and trust to produce the same kind of result every time.

1. What a custom agent is

A GitHub Copilot custom agent is a scoped, named persona with its own instructions, tools, and optional skills. It is defined by a Markdown file with YAML frontmatter and is discoverable from the Chat agent dropdown.

A custom agent can:

Give Copilot a stable role, such as LoadRunner Agent.
Define the tools that the agent is allowed to call.
Encode a workflow such as EXTRACT -> GENERATE -> REVIEW.
Load focused domain knowledge only when a task requires it.
Produce consistent output for everyone working in the repository.
Keep the configuration versioned alongside the code it operates on.

The important distinction is between ad-hoc prompting and an engineered agent. A prompt says what you want right now. An agent defines how a class of requests should be handled, which files may be touched, what checks must run, and what a complete result looks like.

The usual location is:

.github/agents/<name>.agent.md

The agent then appears as a selectable mode in Copilot Chat. Its instructions are not hidden in one engineer's chat history; they are reviewable, changeable, and shareable in source control.

2. The four customization primitives

GitHub Copilot customization has four closely related primitives. They solve different problems, so choosing the right one matters.

Primitive	Purpose	Typical file	How it is activated
Agent	A named persona with tools and a system prompt	`.agent.md`	Selected from the Chat agent dropdown
Skill	Focused domain knowledge or a procedural playbook	`.SKILL.md`	Loaded on demand by an agent or user
Instruction	Always-on rules scoped to matching files	`.instructions.md`	Applied automatically through `applyTo`
Prompt	A reusable, parameterized slash command	`.prompt.md`	Invoked with `/prompt-name`

There are also repository-wide files that help discovery and consistency:

File	Purpose	Location
`copilot-instructions.md`	Rules every chat should see in the workspace	`.github/`
`AGENTS.md`	Repository-level agent index or discovery guide	Repository root

A useful rule of thumb is simple:

Use an agent when the user needs a named role and controlled capabilities.
Use a skill when the agent needs deep knowledge for one phase or capability.
Use an instruction when a rule should apply automatically to matching files.
Use a prompt when people should invoke a repeatable request on demand.

Do not put every rule in the agent body. A large prompt becomes difficult to review, expensive to load, and easy to contradict. Keep the agent responsible for orchestration and move detailed procedures into skills.

3. How the pieces fit together

The relationship between these files is easier to understand as a flow:

flowchart LR
    U[Engineer request] --> A[Custom agent]
    A --> I[System instructions]
    A --> S[Load matching skills]
    A --> T[Call allowed tools]
    I --> T
    S --> T
    T --> F[Files, commands, and search]
    F --> R[Reviewed output]

The agent is the coordinator. Skills provide specialized knowledge. Instructions provide rules that are always in force for a matching file pattern. Tools provide the ability to inspect, modify, or execute.

That separation creates useful boundaries:

The agent decides the phase and sequence.
A skill explains how to perform one phase correctly.
Instructions protect repository conventions.
Tool permissions limit what the agent can actually do.
Human review remains the final control for generated code and side effects.

4. Anatomy of an `.agent.md` file

An agent file has two parts: YAML frontmatter at the top and a Markdown system prompt below it.

A minimal example looks like this:

---
name: LoadRunner Agent
description: Generates, reviews, and summarizes LoadRunner Web Vuser scripts from API project files.
tools:
  - execute/runInTerminal
  - read/readFile
  - edit/createFile
  - edit/editFiles
  - search/codebase
  - search/fileSearch
---

You are an expert LoadRunner script engineer.

Operate in three phases:
EXTRACT -> GENERATE -> REVIEW.

Do not skip a phase. Keep generated files inside the configured output directory.

The four important fields are:

Field	Role
`name`	The label shown in the Chat agent dropdown
`description`	Helps users and Copilot understand when this agent is relevant
`tools`	The allow-list of tool or toolset IDs available to the agent
Body	The system prompt containing phases, rules, boundaries, and completion criteria

The description deserves more care than it usually gets. It should say what the agent produces, what inputs it understands, and when it should be selected. A vague description makes the agent harder to discover and easier to misuse.

5. Tool IDs: use the namespaced form

The most disruptive failure in the walkthrough was also one of the easiest to miss: an agent can appear to load while silently losing the tools it needs because the IDs are wrong.

Use namespaced IDs in the form:

category/toolName

For example:

tools:
  - execute/runInTerminal
  - read/readFile
  - edit/createFile
  - edit/editFiles
  - search/codebase
  - search/fileSearch

The category communicates the capability boundary:

execute/ for commands and terminal execution.
read/ for reading files and content.
edit/ for creating or modifying files.
search/ for codebase, file, or text search.

These forms are not interchangeable with informal names such as runCommands, editFiles, create_file, or read_file:

# Incorrect: raw tool names or toolset names
 tools:
   - runCommands
   - editFiles
   - create_file
   - read_file

# Correct: namespaced tool IDs
 tools:
   - execute/runInTerminal
   - read/readFile
   - edit/createFile
   - edit/editFiles
   - search/codebase

An unknown ID may be dropped without an obvious YAML error. The resulting agent still appears in Chat, but it cannot write files, run the extractor, or search the repository as intended.

After changing the YAML, open the Chat tools picker and verify the exact tool IDs available to the agent. Then reload the agent. Configuration changes do not necessarily hot-reload into an already active chat session.

Tool IDs are a version-sensitive integration detail, not a universal API contract. Treat the names in this post as examples for the environment in which the agent was authored. The Chat tools picker is the source of truth for the exact IDs available in your VS Code installation.

6. Skills: package domain knowledge on demand

A skill is a focused, self-contained playbook for one capability. Skills keep the main agent prompt short while allowing the workflow to carry detailed rules.

A typical location is:

.github/agents/skills/<name>.SKILL.md

For the LoadRunner Agent, the skills can map directly to the workflow:

.github/agents/skills/
    lr-extract.SKILL.md
    lr-generate.SKILL.md
    lr-review.SKILL.md
    lr-parameterize.SKILL.md
    lr-boilerplate.SKILL.md

Each file should have one job:

Skill	Responsibility
`lr-extract`	Detect SoapUI or Postman input and produce normalized request files
`lr-generate`	Convert one normalized request into a LoadRunner C script
`lr-review`	Run the quality checklist and summarize findings
`lr-parameterize`	Build data files from extracted values
`lr-boilerplate`	Generate functional overview documentation

A skill should tell the agent what to read, what to produce, which rules to apply, and how to recognize success. It should not assume that the agent remembers a procedure from an earlier conversation.

The agent can chain several skills when the task crosses phases. That is more maintainable than putting extraction rules, C coding conventions, and review criteria into one giant system prompt.

7. The LoadRunner Agent design

The example agent converts SoapUI or Postman API project files into LoadRunner Web Vuser scripts. Its workflow has three explicit phases:

flowchart TD
    A[Input files in input/] --> B{Detect format}
    B -->|SoapUI XML| C[Run SoapUI extractor]
    B -->|Postman JSON| D[Run Postman extractor]
    C --> E[One normalized .txt per request]
    D --> E
    E --> F[Read one request]
    F --> G[Generate one .c script]
    G --> H{More requests?}
    H -->|Yes| F
    H -->|No| I[Run review checklist]
    I --> J[Pass/fail table and recommendations]

Phase 1: EXTRACT

The agent auto-detects input files in the configured input directory, selects the appropriate extractor, and produces one normalized text payload per API request.

This phase should answer:

Which source format was found?
Which extractor will run?
How many requests were discovered?
Where were the normalized payloads written?
Did extraction produce warnings or incomplete requests?

The extraction result is the contract for the generation phase. If the contract is ambiguous, generation should stop and report the problem instead of guessing.

Phase 2: GENERATE

The agent reads each normalized request one at a time and writes one C script per request. The one-at-a-time rule is deliberate. It avoids loading all payloads into context, reduces cross-request confusion, and makes it clear which input produced which output.

The generation skill can encode rules such as:

Use stable transaction names.
Add Dynatrace correlation headers where required.
Register expected response content with web_reg_find.
Add think time at realistic business boundaries.
Handle request and response errors explicitly.
Preserve the method, URL, headers, and body from the extracted request.
Keep generated output in the repository's locked folder convention.

The agent should write the output immediately after processing each input:

read request-001.txt
write request-001.c
read request-002.txt
write request-002.c
read request-003.txt
write request-003.c

That loop is safer than reading every input file first and attempting to generate all scripts at the end.

Phase 3: REVIEW

The review phase runs a fixed checklist against the generated scripts. It should return evidence, not just a statement that the files look correct.

A useful result contains:

A pass/fail status for each checklist item.
The files examined.
The exact issue for every failed item.
The top three issues that should be fixed first.
The top five recommendations for the next iteration.
Any assumptions that still require a human decision.

The review phase is where an agent becomes more than a file generator. It gives the team a consistent quality gate after generation.

8. A practical agent body

The system prompt should be explicit about phases and boundaries. For example:

You are an expert LoadRunner script engineer.

Your job is to convert SoapUI XML or Postman JSON project files into reviewed
LoadRunner Web Vuser scripts.

Always operate in this order:

1. EXTRACT
   - Detect supported input files under input/soap/ or input/postman/.
   - Run the matching extractor.
   - Confirm the normalized request files that were created.

2. GENERATE
   - Read exactly one normalized request file at a time.
   - Create exactly one .c file for that request.
   - Apply every rule in lr-generate.SKILL.md.
   - Continue until every normalized request has an output file.

3. REVIEW
   - Run every item in lr-review.SKILL.md.
   - Produce a pass/fail table.
   - Report the top three issues and top five recommendations.

Do not invent missing request data. Do not skip extraction or review.
Do not batch-read large collections of input files.
Do not create helper scripts to replace this workflow.
Keep all outputs inside the repository's documented directories.

The details belong in skills, but the agent body must still define the non-negotiable orchestration rules. In particular, say what the agent must not do. Otherwise a general-purpose agent may decide that generating a helper script is a convenient shortcut, even when the agent itself is supposed to perform the work.

A minimal starter set

The smallest useful implementation can be three files. The agent coordinates the workflow, the skill contains the generation rules, and the workspace instructions lock down paths and naming.

.github/agents/loadrunner.agent.md:

---
name: LoadRunner Agent
description: Converts API project files into reviewed LoadRunner Web Vuser scripts.
tools:
    - execute/runInTerminal
    - read/readFile
    - edit/createFile
    - edit/editFiles
    - search/fileSearch
---

Convert supported files under input/ into LoadRunner scripts under output/scripts/.

Always run these phases in order:
1. EXTRACT: identify the input format and create normalized request files.
2. GENERATE: read one normalized request and write one .c file at a time.
3. REVIEW: run the checklist in lr-generate.SKILL.md and report failures.

Do not invent missing request data, batch-read the entire input directory, or create
helper scripts. Keep all generated files under output/.

.github/agents/skills/lr-generate.SKILL.md:

# LoadRunner generation rules

For each normalized request:

- Preserve the HTTP method, URL, headers, and request body.
- Use a stable transaction name derived from the request name.
- Register an expected response with web_reg_find when a reliable check exists.
- Add required Dynatrace headers.
- Add realistic think time only at business-flow boundaries.
- Report missing correlation candidates instead of guessing replacements.
- Write exactly one reviewed candidate script for the input request.

.github/copilot-instructions.md:

- Read source inputs from input/.
- Write generated scripts only to output/scripts/.
- Write review summaries only to output/reports/.
- Use one output file per normalized request.
- Never store credentials, tokens, or production data in generated files.

This starter set is intentionally small. Add extraction, parameterization, and review skills as the workflow gains real requirements, rather than making the first agent responsible for every possible LoadRunner task.

9. Why one file in and one file out matters

Large input collections create two predictable problems:

Context pressure. Reading 29 payloads at once forces summarization, and the agent may need to reread information it already had.
Output ambiguity. When many files are generated together, it becomes harder to detect which input was skipped or which output contains an accidental mix of requests.

A strict loop provides a small checkpoint after every item:

for each normalized request:
    read one request
    generate one output
    verify the output exists
    continue

This is a workflow rule, not a performance optimization. It makes failures local, recoverable, and visible. It also lets a user stop after a particular request without discarding all completed work.

Security and approval boundaries

An agent's tool list is an allow-list, but it is not a complete security boundary. A tool that can run a terminal command or write a file can still have meaningful side effects. Design the agent with the same caution you would apply to a CI job or an automation service account.

Grant only the tools required for the workflow. A read-and-review agent should not receive file-write or terminal permissions.
Keep credentials in environment variables, secret stores, or the platform's approved authentication mechanism. Never place tokens in .agent.md, skills, prompts, examples, or generated scripts.
Treat SoapUI, Postman, and other imported project files as untrusted input. Do not execute commands or URLs found in a payload without an explicit rule allowing that behavior.
Keep generated files inside a known workspace directory and review path-handling rules before enabling terminal execution.
Require human approval for commands that start load tests, modify shared infrastructure, send messages, delete data, or access production systems.
Use test accounts and sanitized request data when demonstrating the workflow or committing sample inputs.

The agent should also report what it did: files read, commands run, files created, warnings, and assumptions. That audit trail makes a generated result easier to review and easier to investigate when something goes wrong.

10. Common pitfalls and fixes

Wrong tool IDs

Symptom: The agent loads but cannot create files or run commands.

Cause: The tools list contains raw tool names or unsupported toolset names.

Fix: Use namespaced IDs such as edit/createFile and execute/runInTerminal. Verify them in the Chat tools picker after every YAML change.

The agent writes a helper script

Symptom: Instead of processing the inputs, the agent creates a Python or shell utility intended to do the work later.

Cause: The prompt did not clearly state that the agent is the program and that helper-script generation is out of scope.

Fix: Add an explicit prohibition to both the agent instructions and the relevant skill. State the permitted tools and the required output directly.

Batch reads exhaust the context

Symptom: The agent summarizes the input collection, loses details, or repeatedly rereads files.

Cause: Large payloads were loaded in one operation.

Fix: Mandate the one-file-in, one-file-out loop and write each result before moving to the next input.

A tool is disabled in the session

Symptom: The YAML is correct, but the agent still cannot call a required tool.

Cause: The tool was unchecked in the Chat tool picker, or the chat session was created before the configuration changed.

Fix: Enable the tool, reload the agent, and start a fresh session when necessary.

Output structure drifts

Symptom: Different runs create different folder layouts or naming conventions.

Cause: The required paths were implied instead of declared.

Fix: Lock folder and naming conventions in .github/copilot-instructions.md and repeat the output contract in the agent or skill that writes the files.

YAML changes appear to do nothing

Symptom: The old description or tool set remains active after editing the agent file.

Cause: The active agent instance has not reloaded its configuration.

Fix: Reload the agent and verify the current tool list before debugging the workflow itself.

11. A repository layout that scales

A small project can begin with this structure:

.github/
    agents/
        loadrunner.agent.md
        skills/
            lr-extract.SKILL.md
            lr-generate.SKILL.md
            lr-review.SKILL.md
            lr-parameterize.SKILL.md
            lr-boilerplate.SKILL.md
    instructions/
        loadrunner.instructions.md
    prompts/
        review-loadrunner.prompt.md
    copilot-instructions.md
AGENTS.md
input/
    soap/
    postman/
output/
    scripts/
    reports/

The names are conventions, not requirements. What matters is that the locations and naming rules are stable enough for the agent, the team, and code review to agree on where things belong.

A useful division of responsibility is:

.agent.md: identity, phases, tool allow-list, and completion behavior.
.SKILL.md: detailed rules for extraction, generation, parameterization, and review.
.instructions.md: file-pattern-specific coding conventions.
copilot-instructions.md: workspace-wide rules and path conventions.
.prompt.md: shortcuts for recurring user requests.
AGENTS.md: a human-readable index of available agents and their intended jobs.

12. Design checklist

Before sharing a custom agent, verify the following:

The agent has one clear job and a useful description.
The file is stored under .github/agents/ and is committed with the repository.
The tool list uses exact namespaced IDs.
The Chat tools picker shows every required tool as enabled.
The system prompt names its phases explicitly.
Detailed domain rules live in focused skills.
Inputs and outputs have fixed paths and naming conventions.
Large input sets are processed one item at a time.
The agent is forbidden from creating helper scripts when direct execution is required.
The workflow reports warnings and assumptions instead of silently guessing.
Generated files receive an explicit review pass.
YAML changes are tested in a newly reloaded agent session.
Side-effecting commands have an approval or review boundary.

Smoke-test the agent before sharing it

Run a deliberately small test after creating or changing the agent:

Reload the agent and confirm the expected tools are enabled in the Chat tools picker.
Provide one sanitized request file, not the full project collection.
Confirm that extraction produces the expected normalized request.
Confirm that generation writes exactly one output file in the documented directory.
Inspect the generated script for method, URL, headers, body, checks, and credentials.
Run the review phase and verify that its report names the file it examined.
Repeat with a malformed or incomplete input and confirm that the agent reports the problem instead of inventing values.

This test catches the most expensive configuration failures early: missing tools, wrong paths, skipped phases, accidental batching, and silent guessing.

13. The larger lesson

Custom agents are small software systems. Their Markdown files may look simple, but the same engineering concerns still apply: interface contracts, permissions, state, failure handling, observability, and tests.

The agent is the orchestration layer. Skills are the domain modules. Instructions are the policy layer. Tools are the execution boundary. A reliable result comes from designing those layers together, then checking that the selected tools and repository paths match the design.

For the LoadRunner example, the winning pattern is straightforward:

EXTRACT -> GENERATE -> REVIEW

Make each phase explicit, keep each skill focused, process large inputs incrementally, and make tool permissions visible. The result is not merely a clever prompt. It is a repeatable engineering workflow that a team can inspect, improve, and run from GitHub Copilot.

14. Quick reference

Need	Put it in	Example
Named specialist with tools	`.agent.md`	`loadrunner.agent.md`
Detailed domain procedure	`.SKILL.md`	`lr-review.SKILL.md`
Rule for matching files	`.instructions.md`	`loadrunner.instructions.md`
Reusable slash command	`.prompt.md`	`review-loadrunner.prompt.md`
Workspace-wide rule	`copilot-instructions.md`	Output paths and naming
Agent discovery index	`AGENTS.md`	Available agents and responsibilities

Common tool ID families:

Tool family	Example
Execute	`execute/runInTerminal`
Read	`read/readFile`
Create	`edit/createFile`
Modify	`edit/editFiles`
Semantic search	`search/codebase`
File search	`search/fileSearch`
Text search	`search/textSearch`

Start with one narrow agent, one clear workflow, and one review checklist. Add skills as the workflow grows; do not make the first agent responsible for everything.

References

Documentation and available tool IDs change over time. Check the current VS Code documentation and the Chat tools picker before copying a configuration into a production repository.

Creating a Custom Copilot Agent for Chaos Engineering Using LitmusChaos and MCP

Kavin Arvind Ragavan — Wed, 23 Sep 2026 19:28:31 +0000

Chaos engineering is often introduced as a command-line or dashboard workflow: install a platform, register a Kubernetes cluster, create an experiment, and run it. That workflow is useful, but it leaves a gap between an SRE's or platform engineer's intent and safe execution.

The engineer should be able to work with the agent through a sequence of small, reviewable prompts: check readiness, inspect the target, review the experiment, approve execution, and verify recovery. This keeps discovery and approval separate from the destructive action.

That is the idea behind this project. I created a custom GitHub Copilot agent whose job is to operate LitmusChaos safely. The agent uses a Go-based Model Context Protocol (MCP) server for LitmusChaos API operations and uses Kubernetes read-only checks to verify local targets and recovery.

This post walks through the agent design, skill workflow, MCP integration, safety model, local Litmus setup, troubleshooting, and lessons learned.

Scope note: This article is about the LitmusChaos MCP integration and the custom Copilot agent. The demo-nginx workload is only an optional local Kubernetes validation target; it is separate from the MCP server and the agent.

Target Audience

This project is intended for engineers who already work with Kubernetes workloads and need a safer, more conversational way to run resilience tests:

Site reliability engineers (SREs) validating service recovery and steady-state behavior.
Platform engineers providing controlled chaos capabilities to development teams.
Chaos engineers designing and running LitmusChaos experiments.
Performance and resilience engineers testing failure behavior under controlled conditions.
Developers who need a disposable local workflow before promoting an experiment to a shared environment.

Throughout this article, the custom agent supports the SRE, platform engineer, or chaos engineer responsible for reviewing and approving a chaos action. It helps make the workflow repeatable, but it does not replace engineering judgment or approval.

The Agent Is the Product

The implementation contains five pieces, but the custom agent is the control layer that ties them together:

Docker Desktop Kubernetes as the local Kubernetes cluster.
LitmusChaos ChaosCenter as the control plane.
Litmus chaos infrastructure deployed into the local cluster.
A Go MCP server that translates MCP tool calls into LitmusChaos GraphQL requests.
A custom Copilot agent that applies preflight checks, safety rules, confirmation gates, execution, and recovery verification.

The agent is designed to work with an explicitly identified workload and environment. It is instructed to reject control-plane namespaces, production environments, and unknown targets unless the responsible engineer provides an approved safety boundary.

Why Create a Custom Agent?

An MCP server exposes capabilities. It does not automatically define a safe operating procedure.

Without an agent, an engineer might ask for a chaos run and jump directly to an execution tool. With an agent, the request becomes a controlled workflow:

natural-language request
  |
  v
find experiment and inspect target
  |
  v
check infrastructure and Kubernetes workload
  |
  v
summarize impact and ask for confirmation
  |
  v
run through MCP and poll status
  |
  v
verify Kubernetes recovery and report evidence

The agent does not replace LitmusChaos. It provides an opinionated operating model around LitmusChaos.

Custom Agent Structure

The workspace agent is defined in:

.github/agents/litmuschaos.agent.md

Its frontmatter restricts the agent to the Litmus MCP server plus read-only or observational terminal work:

---
description: "Use for LitmusChaos MCP operations: inspect experiments, validate local Kubernetes chaos targets, run or stop disposable chaos experiments, investigate queued or failed runs, and report recovery. Requires confirmation before destructive actions."
name: "LitmusChaos Operator"
tools: [litmuschaos/*, execute, read]
user-invocable: true
---

The agent body defines the behavior that matters more than the persona:

Inspect before executing.
Verify the infrastructure is active and confirmed.
Verify the namespace and workload selector.
Ask for explicit confirmation before run or stop operations.
Never expose the access token.
Verify the target recovers after the experiment.

The Agent Skill

The repeatable run workflow lives in:

.github/skills/litmus-experiment-runner/SKILL.md

The skill is deliberately procedural. It tells the agent to:

Find the experiment by name when necessary.
Load the full experiment definition.
Check infrastructure state.
Validate the target namespace and selector.
Present a confirmation summary.
Run the experiment through MCP.
Poll the run until it reaches a terminal state.
Verify Kubernetes recovery.

This separation is useful: the .agent.md file defines the agent's role and boundaries, while the skill defines a reusable operational workflow.

Tutorial: Create the Agent and Skill

This is the smallest useful implementation. The agent defines the operating policy; the skill defines the repeatable run procedure.

1. Register the MCP Server

Create .vscode/mcp.json in the workspace:

{
  "servers": {
    "litmuschaos": {
      "type": "stdio",
      "command": "${workspaceFolder}/litmus-mcp-server/bin/litmuschaos-mcp-server.exe",
      "envFile": "${workspaceFolder}/litmus-mcp-server/.env"
    }
  }
}

Keep the token in the ignored .env file. Do not embed it in the agent, skill, README, screenshots, or chat prompts.

2. Create the Custom Agent

Create .github/agents/litmuschaos.agent.md:

---
description: "Operate LitmusChaos through MCP with target validation and confirmation gates."
name: "LitmusChaos Operator"
tools: [litmuschaos/*, execute, read]
user-invocable: true
---

You are the LitmusChaos Operator.

- Inspect experiments and infrastructure before execution.
- Verify the target namespace and workload.
- Require explicit confirmation before run or stop operations.
- Never expose credentials.
- Verify Kubernetes recovery after a local experiment.

The description is important because it is the agent's discovery surface in VS Code. The body establishes behavior and safety boundaries.

3. Add the Operational Skill

Create .github/skills/litmus-experiment-runner/SKILL.md:

---
name: litmus-experiment-runner
description: 'Run safe LitmusChaos experiments through MCP with preflight, confirmation, polling, and recovery checks.'
---

# Litmus Experiment Runner

1. Find the experiment by name or ID.
2. Inspect the experiment definition and infrastructure.
3. Verify the namespace and workload selector.
4. Summarize impact and ask for confirmation.
5. Run through MCP only after confirmation.
6. Poll the run until it reaches a terminal state.
7. Verify Kubernetes recovery.

A skill is a good fit here because the sequence is reusable and procedural. Keep policy in the agent and task-specific procedure in the skill.

4. Select the Agent in Copilot Chat

Reload the VS Code window if needed, select LitmusChaos Operator in the agent picker, and use Agent mode.

Start with a read-only request:

Check whether Litmus is ready for a chaos test, then list my chaos experiments.

For an execution request against the optional local validation target, the agent should ask for confirmation:

Run the local `pod-delete-1` experiment against `demo-nginx` in namespace `chaos-test`.
Inspect the experiment and infrastructure first, then ask for confirmation.

After confirmation, the agent can call run_chaos_experiment, poll list_experiment_runs, and use Kubernetes read-only commands to verify the local test Deployment recovered. The MCP server and custom agent remain the subject of this article; demo-nginx is only a sample workload used to exercise them.

5. Test the MCP Server Directly

The MCP transport can be tested independently of the agent with a read-only JSON-RPC request:

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_chaos_experiments","arguments":{}}}

This distinction helps debugging:

If MCP discovery fails, inspect .vscode/mcp.json and server startup logs.
If MCP works but the run fails, inspect the experiment, infrastructure, workflow, and Kubernetes events.
If the agent skips confirmation, tighten the agent instructions and skill procedure.

Architecture

The request path looks like this:

Copilot Chat
    |
    | MCP over stdio
    v
LitmusChaos MCP server (Go)
    |
    | HTTP GraphQL request
    v
ChaosCenter GraphQL server
    |
    | WebSocket/subscriber communication
    v
Litmus chaos infrastructure in Kubernetes
    |
    v
ChaosEngine and experiment runner
    |
    v
Target workload in the approved application namespace

The MCP server is a local stdio process. VS Code starts it from .vscode/mcp.json, and the process reads credentials from a local .env file.

A simplified MCP configuration looks like this:

{
  "servers": {
    "litmuschaos": {
      "type": "stdio",
      "command": "${workspaceFolder}/litmus-mcp-server/bin/litmuschaos-mcp-server.exe",
      "envFile": "${workspaceFolder}/litmus-mcp-server/.env"
    }
  }
}

The MCP server exposes these 16 enabled tools:

Tool	Purpose
`list_chaos_experiments`	Discover experiments with optional filters and pagination.
`get_chaos_experiment`	Inspect an experiment, including its manifest and infrastructure.
`run_chaos_experiment`	Start an existing experiment immediately.
`stop_chaos_experiment`	Stop an active experiment or specific run.
`list_experiment_runs`	Review experiment run history and filter by status.
`get_experiment_run_details`	Inspect a run, execution state, and optional logs.
`list_chaos_infrastructures`	Find registered infrastructures and filter by status.
`get_infrastructure_details`	Inspect infrastructure details and optionally its manifest.
`register_chaos_infrastructure`	Create an infrastructure registration request.
`list_environments`	List environments used to organize infrastructures.
`create_environment`	Create a `PROD` or `NON_PROD` environment.
`list_resilience_probes`	Discover configured resilience probes.
`create_resilience_probe`	Create supported HTTP, command, Kubernetes, or Prometheus probes.
`list_chaos_hubs`	Discover available ChaosHubs.
`get_chaos_faults`	Browse faults exposed by a ChaosHub.
`get_experiment_statistics`	Review experiment and resiliency-score statistics.

The server currently exposes 16 enabled tools. Experiment creation is intentionally disabled: create and configure experiments in ChaosCenter first, then use MCP to list, inspect, run, stop, and review them.

What the MCP Server Does

The Go server is an API adapter. It accepts MCP tool calls over standard input and output, adds the configured project ID and bearer token to the request, calls the ChaosCenter GraphQL endpoint, and returns structured results to Copilot. It does not inspect Kubernetes workloads, decide whether a target is safe, or approve a destructive action.

Those responsibilities belong to the custom agent and its skill. Before a run, the agent reads the experiment manifest returned by get_chaos_experiment, checks that the manifest target matches the requested workload, verifies the infrastructure, and asks for explicit confirmation. After starting a run, it treats the start response as an acknowledgement rather than proof of success, polls the run, and investigates the workflow when the run remains active beyond its expected duration.

This separation also makes failures easier to diagnose:

MCP connectivity failure: the local GraphQL endpoint or port-forward is unavailable, so the server cannot reach ChaosCenter.
API failure: ChaosCenter rejects the GraphQL request or returns an error.
Workflow failure: ChaosCenter accepts the request, but Kubernetes or Argo rejects or cannot execute the generated workflow.
Target verification failure: the experiment manifest does not match the requested workload, or the local Kubernetes check cannot verify it.

The agent should report which layer failed and should not retry a destructive action automatically.

Experiment Coverage

MCP is not a second experiment catalog. It controls experiments already created in the configured ChaosCenter project, so the available experiments depend on the ChaosHub faults and probes installed there. Depending on that project, an engineer may use MCP with pod or container disruption, CPU or memory stress, network or storage faults, node-level faults, and probe-backed experiments that check HTTP, Kubernetes, command, or Prometheus signals.

The reliable workflow is to discover the actual catalog first:

List my chaos experiments.
Show the available faults in ChaosHub <hub-id>.
Show details for experiment <experiment-id>, including its manifest and recent runs.

These are capability categories, not a guarantee that every Litmus installation contains every fault. The ChaosHub and the experiment definition determine which faults and parameters are available.

Prerequisites

You need:

Windows with Docker Desktop
Docker Desktop Kubernetes enabled
kubectl
Helm 3 or later
Go 1.21 or later to build the MCP server
A LitmusChaos project and API token
VS Code with Copilot Chat and MCP support

A full ChaosCenter installation is resource-heavy for a small laptop. My host had 8 GB of RAM and an i3 processor, so WSL 2 was configured conservatively:

[wsl2]
memory=4GB
processors=2
swap=2GB
localhostForwarding=true

The WSL configuration lives at:

%UserProfile%\.wslconfig

After changing it, apply the settings with:

wsl --shutdown

Install ChaosCenter

First, select the local Docker Desktop context:

kubectl config use-context docker-desktop
kubectl get nodes

The node should be Ready.

Add the Litmus Helm repository:

helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm repo update

For a constrained laptop, use a single MongoDB replica set member rather than the default three-member configuration:

helm install chaos litmuschaos/litmus `
  --namespace litmus `
  --create-namespace `
  --set portal.frontend.service.type=NodePort `
  --set mongodb.architecture=replicaset `
  --set mongodb.replicaCount=1 `
  --set mongodb.persistence.size=1Gi `
  --wait --timeout 15m

The important detail is architecture=replicaset with replicaCount=1. A standalone MongoDB setting looked attractive for a low-resource installation, but Litmus init containers expected the StatefulSet DNS name chaos-mongodb-0.chaos-mongodb-headless. A one-member replica set preserves that expected service-discovery behavior.

Verify the installation:

kubectl get pods -n litmus
kubectl get svc -n litmus

Forward the ChaosCenter frontend:

kubectl port-forward -n litmus svc/chaos-litmus-frontend-service 9091:9091

Open:

http://localhost:9091

Sign in with the administrator credentials configured for your local installation, and change the initial password immediately. Do not publish administrator credentials, tokens, or screenshots containing them.

Register the Local Chaos Infrastructure

ChaosCenter requires an environment and an infrastructure before it can run experiments.

Create a non-production environment, for example:

Name: local-docker
Type: NON_PROD
Description: Local Docker Desktop Kubernetes test environment

Use ChaosCenter's Enable Chaos workflow to generate the infrastructure manifest. Apply the downloaded YAML with:

kubectl config use-context docker-desktop
kubectl apply -f local-docker-chaos-litmus-chaos-enable.yml

The manifest installs components including:

Chaos operator
Chaos exporter
Subscriber
Event tracker
Workflow controller
Litmus CRDs and RBAC

Check readiness:

kubectl get pods -n litmus
kubectl logs -n litmus deployment/subscriber --tail=80

A useful confirmation in the subscriber log is:

AgentID ... has been confirmed
Server connection established, Listening....

On a 2 CPU local node, the generated infrastructure requests may exceed available CPU. For local validation, reduce only the infrastructure deployment requests:

kubectl set resources deployment/chaos-operator-ce deployment/chaos-exporter deployment/subscriber deployment/event-tracker deployment/workflow-controller `
  -n litmus --requests=cpu=50m,memory=100Mi

This is a local scheduling workaround, not a production sizing recommendation.

Connect the MCP Backend

From the server directory:

cd litmus-mcp-server
go test ./...
go build -o .\bin\litmuschaos-mcp-server.exe .

The server uses these environment variables:

CHAOS_CENTER_ENDPOINT=http://localhost:9002
LITMUS_PROJECT_ID=your-project-uuid
LITMUS_ACCESS_TOKEN=your-token
DEFAULT_INFRA_ID=your-infrastructure-id
DEFAULT_ENVIRONMENT_ID=your-environment-id

The project ID is the UUID in the ChaosCenter project URL, not the display name. For example, a URL like:

/account/<account-id>/project/<project-id>/dashboard

contains the project ID after /project/.

Forward the GraphQL server used by the MCP implementation:

kubectl port-forward -n litmus svc/chaos-litmus-server-service 9002:9002

The local MCP endpoint is then:

http://localhost:9002

The frontend port 9091 is for the browser UI. The MCP server should use the GraphQL port 9002.

Set Up a Local Validation Target

Create an isolated test namespace and workload:

kubectl create namespace chaos-test --dry-run=client -o yaml | kubectl apply -f -
kubectl create deployment demo-nginx `
  --image=nginx:alpine `
  --replicas=1 `
  -n chaos-test `
  --dry-run=client -o yaml | kubectl apply -f -

kubectl rollout status deployment/demo-nginx -n chaos-test

The expected label is:

app=demo-nginx

The experiment should target this Deployment, not a pod name. Kubernetes will replace the pod after the fault runs.

Create the Experiment

In ChaosCenter, create a Pod Delete experiment from a ChaosHub template.

Recommended local values:

App kind: deployment
App namespace: chaos-test
App label: app=demo-nginx
Total chaos duration: 15 seconds
Ramp time: 0
Chaos interval: 5 seconds
Pods affected: 100 percent
Default health check: false
Sequence: parallel

For the first test, either use no probe or create a Kubernetes probe that checks:

Group: apps
Version: v1
Resource: deployments
Resource name: demo-nginx
Namespace: chaos-test
Operation: present

The probe must be attached to the Pod Delete fault, not to a workflow helper step such as run-chaos. Litmus stores the relationship in an annotation similar to:

annotations:
  probeRef: '[{"name":"k8sprobe","mode":"SOT"}]'

The probe name must exactly match the saved probe name. A stale or mismatched probe reference causes errors such as:

Probe in fault is not attached to a proper reference

Select and Test the Custom Agent

In Copilot Chat, select the LitmusChaos Operator custom agent and use Agent mode. Start with a read-only request:

Check whether Litmus is ready for a chaos test, then list my chaos experiments.

A successful response includes the experiment name and ID. The agent should also report whether the infrastructure is active and confirmed. The server returned a successful read-only response with zero experiments before the experiment was created, which was a useful first connectivity test.

Run Through the Custom Agent

The safe conversational workflow is:

Run the pod-delete experiment through LitmusChaos.
First inspect the experiment and infrastructure.
Verify that the target is only demo-nginx in the chaos-test namespace.
Ask for confirmation before running it.

The agent should resolve the display name to an experiment ID and then call MCP. Before execution, it should verify:

Infrastructure is active
Infrastructure is confirmed
The target namespace is chaos-test
The target selector is app=demo-nginx
The experiment is not pointed at litmus, kube-system, or production

Monitor Kubernetes in another terminal:

kubectl get pods -n chaos-test -w

For a successful Pod Delete experiment, the target pod disappears and the Deployment creates a replacement pod.

The important design decision is that the agent does not silently execute a destructive tool. It turns the request into a preflight report and confirmation gate first.

Small Prompts for the Agent

Use these prompts one at a time. Wait for the agent's result before sending the next prompt.

Prompt 1: Check Readiness

Is Litmus ready for a local chaos test?

Prompt 2: Check the Target

Check `Deployment/demo-nginx` in namespace `chaos-test`.

Prompt 3: List Experiments

List my chaos experiments.

Prompt 4: Inspect the Experiment

Show details for `pod-delete-1`.

Prompt 5: Validate the Target

Verify that `pod-delete-1` targets only `demo-nginx` in `chaos-test`.
Do not run it.

Prompt 6: Ask for a Preflight

Prepare the preflight summary for `pod-delete-1`.

Prompt 7: Request Execution

Run `pod-delete-1`.
Ask for confirmation first.

Prompt 8: Confirm Execution

Only send this after reviewing the preflight summary:

Yes, run it.

Prompt 9: Check the Run

What is the status of the latest run?

Prompt 10: Verify Recovery

Verify that `demo-nginx` recovered.

Prompt 11: Investigate Failure

Why did the latest run fail or remain queued?

Prompt 12: Stop Safely

Check whether the experiment is still running.

If it is still active, review the target and then send:

Stop the active run. Ask for confirmation first.

Prompt 13: Inspect Infrastructure

List only active chaos infrastructures.
Show details and the installation manifest for infrastructure <infra-id>.

Prompt 14: Manage Environments

List NON_PROD environments.
Create a NON_PROD environment named local-test with description "Disposable Kubernetes test environment".
Ask for confirmation before creating it.

Prompt 15: Work With Resilience Probes

List Kubernetes resilience probes.
Create a Kubernetes probe that checks whether Deployment/demo-nginx exists in namespace chaos-test, with a 5 second timeout and 5 second interval.

Prompt 16: Discover ChaosHubs and Faults

List all ChaosHubs.
Show pod-related faults available in ChaosHub <hub-id>.

Prompt 17: Review Statistics

Show experiment statistics including resiliency score distribution.
Give me a read-only health summary of experiments, infrastructures, environments, and ChaosHubs.

Prompt 18: Register Infrastructure

Register a namespace-scoped Kubernetes infrastructure named local-test-2 in environment <environment-id>.
Show me the request details and ask for confirmation before creating it.

Creating an environment or infrastructure registration request changes ChaosCenter state, so the agent should confirm those actions too. Creating an experiment definition remains a ChaosCenter UI workflow in this implementation.

This incremental style keeps each decision visible. The agent should never combine discovery, approval, execution, and recovery into one opaque action.

What Failed During the Build

The setup produced several useful lessons.

Docker Desktop Kubernetes was unstable at 2 GB

The default Docker Desktop resource limit was 2 GB. ChaosCenter starts several services and MongoDB, so the Kubernetes API repeatedly became unavailable with TLS handshake timeouts.

The practical fix was to configure WSL 2 with 4 GB and 2 CPUs, then use a reduced MongoDB configuration and smaller infrastructure requests.

Standalone MongoDB broke expected DNS

A standalone MongoDB deployment removed the StatefulSet hostname expected by Litmus init containers. The compatible low-resource choice was a one-member replica set.

Helm retained a pending operation

An interrupted Helm installation left the release in pending-install. The clean recovery was:

helm uninstall chaos -n litmus
kubectl delete namespace litmus
kubectl create namespace litmus

Then install the chart again with the corrected values.

Generated Argo labels were invalid

The generated workflow used a label value containing an unresolved template:

subject: "{{workflow.parameters.appNamespace}}_pod-delete"

Kubernetes rejected the literal braces because they are not valid label characters. A static value such as this is valid:

subject: chaos-test_pod-delete

This is a general lesson: do not assume every workflow field expands templates. Labels are validated before Argo can necessarily substitute workflow parameters.

The first MCP run was queued and rejected

The MCP request itself succeeded and returned a success response, but the resulting workflow was rejected by Kubernetes because of the invalid label. That distinction matters:

MCP transport: working
ChaosCenter API: reachable
Infrastructure: confirmed
Workflow validation: failed

A successful MCP request does not guarantee that the generated chaos workflow will execute successfully. Always inspect the run status and Kubernetes events.

Keep Local Validation Repeatable

The repository includes an optional helper for restarting the local validation environment:

powershell -ExecutionPolicy Bypass -File .\scripts\start-litmus-demo.ps1

It:

Starts Docker Desktop if necessary.
Selects the docker-desktop Kubernetes context.
Waits for the local node.
Waits for Litmus deployments.
Verifies or recreates the local validation workload.
Starts the 9091 frontend port-forward.
Starts the 9002 GraphQL port-forward.

Stop the port-forwards without deleting Kubernetes resources:

powershell -ExecutionPolicy Bypass -File .\scripts\stop-litmus-demo.ps1

This makes normal Windows or Docker Desktop restarts cheap. A Docker Desktop Reset Kubernetes cluster is different: it deletes the local Kubernetes resources and requires reinstalling ChaosCenter and the infrastructure manifest.

References and Useful Links

For the complete workspace implementation, the relevant files are:

.github/agents/litmuschaos.agent.md
.github/skills/litmus-experiment-runner/SKILL.md
.vscode/mcp.json
litmus-mcp-server/MCP_CHAT_GUIDE.md

Attribution

This project and tutorial integrate and build on:

LitmusChaos and the LitmusChaos project for chaos orchestration, experiments, ChaosCenter, and GraphQL APIs.
Model Context Protocol for the tool-transport contract.
Go for the MCP server implementation.
Kubernetes and Docker Desktop for the local execution environment.
Visual Studio Code Copilot customization for the custom agent and skill workflow.

The MCP server integration, custom agent instructions, skill workflow, restart scripts, and tutorial content in this repository are custom project work. Please consult each upstream project's repository and license before redistributing code, documentation, or generated experiment assets. LitmusChaos, Kubernetes, Docker, GitHub Copilot, VS Code, and related product names are trademarks or project names of their respective owners.

The custom agent instructions, skill workflow, restart scripts, and supporting documentation in this tutorial were created for this example. Replace local IDs, endpoints, credentials, and infrastructure details with your own values before publishing or sharing the repository.

Security Notes

Do not publish:

.env
API tokens
Infrastructure access keys
Downloaded infrastructure manifests containing credentials
Private project or account identifiers unless intentionally redacted

The .env file is ignored by Git, but a Git ignore rule does not protect a token that has already appeared in chat logs, screenshots, terminal transcripts, or public commits. Rotate any token that was exposed during testing.

For a team or public blog, replace all real values with placeholders:

LITMUS_PROJECT_ID=<project-uuid>
LITMUS_ACCESS_TOKEN=<redacted-token>
DEFAULT_INFRA_ID=<infrastructure-uuid>

Final Takeaways

The custom Copilot agent is the central design artifact. LitmusChaos remains the chaos platform, Kubernetes remains the execution environment, and MCP provides the API bridge. The agent supplies the operational discipline around those systems.

MCP does not replace Kubernetes or ChaosCenter. It adds a conversational control layer over existing APIs and workflows, while the custom agent turns that capability into a repeatable and safer SRE and resilience-engineering workflow.

The most reliable pattern is:

preflight -> inspect -> confirm -> execute -> poll -> verify recovery

The preflight and confirmation steps are not ceremony. They are what prevent a natural-language request from becoming an accidental production outage.

For a small local machine, resource sizing is part of the experiment design. A constrained target and a restart helper make local validation repeatable without pretending that a laptop-sized cluster is production infrastructure.

The reusable pattern is broader than LitmusChaos:

custom agent policy
  +
MCP tools
  +
domain-specific skill
  +
explicit confirmation
  =
conversational operations with guardrails

Building an AI Agent for Performance Engineering: MCP Servers You Can Use Today

Kavin Arvind Ragavan — Fri, 18 Sep 2026 18:54:40 +0000

MCP Servers for Performance, Observability and Resilience Engineering

Many widely used performance, observability, resilience, and browser-testing platforms now have an MCP server sitting in front of them. That means you can stop opening five different consoles to answer one question about a load test, and instead ask for the answer directly: "did checkout regress in the last run," "audit this page on mobile," "run a pod-delete and give me the resiliency score." The server does the API calls; you just describe the outcome.

This post is the practical map for doing that: what each server actually lets you do as a performance engineer, the real tools behind each capability, the configuration you need to get it running, and a worked usage scenario for every one. Twelve servers, five categories — load and stress testing, observability and evidence, resilience and chaos engineering, front-end/client-side testing, and browser automation — all documented with the parameters you'll pass.

How to use this post: skim the category you care about, read the "usage in practice" example to see what a real request looks like, then use the tool table as your reference when you wire it into an agent. Within every category, vendor-maintained servers are listed first, community servers next — so the trust tier is visible before you even reach the details.

Catalog snapshot: Tool counts, transports, configuration options, and project status were checked against the referenced repositories around September 2026. MCP servers evolve quickly, so treat these counts as a point-in-time snapshot rather than permanent API contracts.

1. The shape every one of these servers follows

Before the catalog, the pattern worth internalizing: most MCP servers here are thin, typed adapters over an existing platform's API or CLI. Nothing more.

┌────────────────────┐        ┌───────────────────────┐        ┌───────────────────────┐
│   MCP Client         │        │   MCP Server            │        │   Underlying Platform  │
│  (Copilot, Claude,    │──────▶│   (this catalog)         │──────▶│  (LoadRunner, Dynatrace,│
│   Cursor, ...)        │◀──────│   typed tools, schemas   │◀──────│   Splunk, JMeter, ...)  │
└────────────────────┘        └───────────────────────┘        └───────────────────────┘
        tools/list                  auth: token / key /              REST, GraphQL, DQL,
        tools/call                  OAuth / CLI child-proc            CLI subprocess, etc.

What varies between servers is the transport (stdio vs. SSE vs. HTTP), the auth model (static keys vs. OAuth vs. browser-based token exchange), and — the part worth reading carefully — what a tool call can actually do: read-only investigation, or an action with a real-world side effect (spend money, send a message, start a test, delete data).

The practical flow looks like this: the MCP server exposes capabilities, the agent decides how to use them, and policy controls actions that need approval.

flowchart LR
        A[Engineer request] --> B[Copilot agent]
        B --> C[Discover MCP tools]
        C --> D[Plan tool sequence]
        D --> E{Approval needed?}
        E -->|Yes| F[Human approval]
        E -->|No| G[Call MCP server]
        F --> G
        G --> H[Underlying platform]
        H --> I[Evidence and result]
        I --> B

2. Trust tiers, at a glance

Not every server here deserves the same confidence. I use two tiers throughout this reference, and within every category below, servers are listed vendor-maintained first, community next:

Tier	Meaning	Servers in this catalog
🟢 Vendor-maintained	Maintained by the platform vendor or product team	k6, BlazeMeter, LitmusChaos, Chrome DevTools MCP, Playwright MCP
🔵 Community, verified	Third-party, source read and confirmed	LoadRunner Cloud, Apache JMeter, Artillery, Dynatrace, Splunk, Lighthouse, PageSpeed Insights

Five of the twelve servers are vendor-maintained projects — more than I expected when I started this catalog. The remaining seven are community-verified projects, with their source and documented tool surfaces reviewed for this catalog.

3. Load & stress testing

3.1 k6 MCP

Repo: grafana/mcp-k6 · Language: Go · Status: 🟢 vendor-maintained (Grafana Labs) — the maintainers mark it experimental
Runtime: stdio by default, optional Streamable HTTP (-transport=http) — ships as a Docker image, Homebrew formula, Debian/RPM packages, a native Go binary, or an xk6 subcommand
Config: none required for local use beyond having k6 on PATH (or using the Docker image, which bundles it); HTTP mode adds -addr, -endpoint, -stateless, -preload
Auth: none built in — the README is explicit that a remote deployment needs a trusted network or a proxy in front of it

k6 scripts are JavaScript, and JavaScript is forgiving about compiling into something that silently does the wrong thing. Plenty of k6 users have shipped a "test" that ran zero real iterations because of a scenario-config typo, and only found out from a suspiciously fast pass.

Benefits:

validate_script catches structural mistakes before you burn a real run on them — a minimal dry run at 1 VU, 1 iteration
The generate_script prompt template drafts a starting script from a plain-English description, grounded in the actual k6 docs rather than a stale training snapshot
The documentation tools (list_sections, get_documentation) let the agent look up the current k6 API instead of guessing at option names
Works the same whether you run it locally via Docker or point your whole team at one shared HTTP instance

Usage in practice: "generate a k6 script that load-tests our login API with authentication, then validate it" pulls the current k6 docs for scenarios and thresholds, drafts a script, and immediately runs validate_script against it — catching a bad stages array before you ever spend a real run on it.

Tool	Parameters	What it does
`validate_script`	`script`	Dry-runs the script (1 VU, 1 iteration) and returns pass/fail plus stdout/stderr
`run_script`	`script`, `vus?`, `duration?` (max 5m), `iterations?`	Executes the test locally and returns metrics and a summary
`list_sections`	`version?`, `category?`, `depth?` (default 1, max 5), `root_slug?`	Browses the k6 docs tree without loading all of it into context
`get_documentation`	`slug`, `version?`	Retrieves the full markdown for one docs section
`info`	(none)	Reports k6 and server environment information
`search_terraform`	`query`	Searches the k6 Terraform documentation

The current server exposes six tools. It also provides a generate_script prompt template (resource URI prompts://k6/generate_script) that chains research, best practices, and validation into one guided flow.

Good for: going from "describe the test in English" to a validated k6 script without leaving the conversation — and it's the one server here where the maintainers are upfront that it's still experimental, so budget for rough edges.

3.2 BlazeMeter MCP

Repo: Blazemeter/bzm-mcp · Language: Python 3.11+ · Status: 🟢 vendor-maintained (published by BlazeMeter/Perforce)
Runtime options: pre-built binary, uvx (from git), or Docker (ghcr.io/blazemeter/bzm-mcp)
Config: API_KEY_ID + API_KEY_SECRET (or a BLAZEMETER_API_KEY JSON file), SOURCE_WORKING_DIRECTORY for Docker mounts, optional SSL_CERT_FILE for corporate CA bundles

It's the one entry on this list you can point at a compliance review without an argument — a vendor-maintained server, from the company that makes the product.

Benefits:

OpenTelemetry ships out of the box, so you get observability into the agent's behavior for free, not just the load test's
Three install paths (binary, uvx, Docker) mean it fits whatever your team already standardized on
Cloud-scale execution without you having to run or scale your own load generators

Usage in practice: a quarterly capacity test that used to mean someone manually clicking through the BlazeMeter console becomes "launch the payments load test in the cloud and tell me how it went" — the agent starts the run, waits, and reports back with the summary, while OpenTelemetry quietly records how long each of those calls actually took.

This is the one vendor-maintained server in the load-testing category. Its tool surface covers the full cloud workflow — creating and managing load-test workflows, executing them, and retrieving reports — but BlazeMeter documents the exact tool list in their own MCP Server guide rather than enumerating every tool in the README, so treat the specific tool names as vendor-documented rather than independently verified here.

Observability bonus: it ships OpenTelemetry instrumentation out of the box — every tool call produces a trace (tool name, action, client name/version, session ID) and two metrics (mcp.tool.calls, mcp.tool.duration). Telemetry defaults to BlazeMeter's own collector; you can redirect it (OTEL_EXPORTER_OTLP_ENDPOINT) or disable it (OTEL_SDK_DISABLED=true or --no-telemetry).

Good for: cloud-scale execution when you're already a BlazeMeter customer and want the vendor's own supported path.

3.3 LoadRunner Cloud MCP

Repo: pbandreddy/loadrunner-cloud-mcp-server · Language: JavaScript (ESM) · Status: 🔵 community
Runtime: Node.js 18+ (20+ recommended) · @modelcontextprotocol/sdk 1.9.0 · stdio by default, optional SSE (--sse)
Config: LRC_BASE_URL, LRC_TENANT_ID, LRC_CLIENT_ID, LRC_CLIENT_SECRET, optional PORT (SSE mode)
Auth: client credentials exchanged for a bearer token automatically before every call

Engineers finish a spike test and then lose the next quarter hour clicking through the LoadRunner Cloud UI to find the run, open the transactions tab, and eyeball whether p95 crossed the line. This server exists to compress that click-through into a question.

Benefits:

No more hunting for a run ID by hand — the tool chain resolves project → test → run for you
Percentile math (p90/p95) comes back built into the response, not something you compute from a raw CSV export
Read-only by construction, so pointing an agent at it can't accidentally trigger a new test run
One call (test_runs_getHttpResponses) gets you straight to the failure evidence instead of a support ticket

Usage in practice: picture this — your spike test on checkout just finished. Instead of opening a browser, you ask "did checkout regress in the last run?" The agent resolves the project with get_projects, walks to the latest run through projects_getLoadTestRuns, then pulls test_runs_getTestRunTransactions for the percentile table and test_runs_getHttpResponses if anything looks off. Thirty seconds later you have an answer instead of a browser tab.

This server is read-only — it's built for investigating existing LoadRunner Cloud projects and runs, not for launching new ones. All nine tools require TENANTID under the hood; you never pass it yourself.

Tool	Parameters	What it returns
`get_projects`	(none)	All projects in the tenant
`projects_getLoadTests`	`projectId`	Load tests for a project
`projects_getLoadTestScripts`	`projectId`, `loadTestId`	Scripts attached to a load test
`projects_getLoadTestRuns`	`projectId`, `loadTestId`	Runs for a load test
`get_active_test_runs`	`status?`, `projectIds?`	Currently active runs, filterable by status (`RUNNING`, `INITIALIZING`, `CHECKING_STATUS`, `STOPPING`, `DELAYED`)
`test_runs_getRecentTestRuns`	`projectIds?`	License usage for runs in the last 30 days
`test_runs_getTestRunResults`	`runId`	Overall result/status for a run
`test_runs_getTestRunTransactions`	`runId`	Transaction data — the call always requests the 90th and 95th percentile
`test_runs_getHttpResponses`	`runId`	HTTP response detail for a run

Good for: "what's the p95 on the latest checkout run" style investigation, without opening the LRC UI.

3.4 Apache JMeter MCP ("JMeter Architect")

Repo: aravindksk7/Jmeter-MCP · Language: TypeScript → dist/index.js · Status: 🔵 community
Runtime: Node.js 18+ · Apache JMeter itself only required for the run tool, on PATH
Config: invoked as node dist/index.js; JMeter's bin directory must be on PATH for jmeter_run_test to work

Ask any engineer who's used JMeter's desktop GUI to add a Header Manager, and you'll get a specific kind of sigh. This server routes around the GUI entirely.

Benefits:

No hand-edited XML — the tools assemble a structurally valid .jmx for you, element by element
Executes in non-GUI mode from the start, so the same plan you build in chat is the one that runs in CI
Assertions and listeners are added as explicit tool calls, so nothing gets silently skipped the way it can in a GUI where a checkbox is easy to miss

Usage in practice: "build a 100-user checkout test with a 200-status assertion and run it" turns into a real sequence: jmeter_init_plan, then a thread group at 100 users, a sampler for the checkout endpoint, an assertion on the response code, a listener for the aggregate report, and finally jmeter_run_test. You get a working .jmx and a completed run without opening the JMeter desktop app once.

This one doesn't call an existing JMeter installation to build a plan — it constructs a real .jmx file, element by element, then hands it to JMeter to execute in non-GUI mode.

Tool	Required parameters	What it does
`jmeter_init_plan`	`filename`	Creates a fresh, empty `.jmx` test plan
`jmeter_add_thread_group`	`filename`, `num_threads`, `ramp_time`, `loops`	Adds virtual users (`loops: -1` = infinite)
`jmeter_add_sampler`	`filename`, `domain`, `path`, `method`, `parameters`	Adds an HTTP request
`jmeter_add_header`	`filename`, `headers`	Adds an HTTP Header Manager
`jmeter_add_listener`	`filename`, `listener_type` (`summary` \	`aggregate` \
`jmeter_add_timer`	`filename`, `delay_ms`, `random_delay_ms?`	Adds think time between requests
`jmeter_add_assertion`	`filename`, `test_field` (`response_data` \	`response_code` \
`jmeter_run_test`	`filename`, `output_file?`	Executes the plan in non-GUI mode

Good for: building a correct .jmx from a sentence instead of hand-editing XML — genuinely useful if you've ever fought JMeter's GUI to add a Header Manager.

3.5 Artillery MCP

Repo: jch1887/artillery-mcp-server · Language: TypeScript · Status: 🔵 community
Runtime: Node.js 22.18+ · requires the Artillery CLI on PATH (or ARTILLERY_BIN) · stdio
Config: ARTILLERY_WORKDIR, ARTILLERY_BIN, ARTILLERY_TIMEOUT_MS (default 1,800,000 ms / 30 min), ARTILLERY_MAX_OUTPUT_MB (default 10), ARTILLERY_ALLOW_QUICK (default true), DEBUG
Sandbox: every path is resolved inside ARTILLERY_WORKDIR; the child process environment is an explicit allow-list, not inherited wholesale

Artillery is one of the fastest load tools to spin up, but its CLI output is a wall of JSON you re-parse by eye after every run, and the YAML configs tend to live wherever the last person who wrote one happened to save them.

Benefits:

Saved configs mean "the smoke test for the payments API" lives in one named place instead of six local copies
Built-in regression thresholds turn "looks about the same to me" into an actual pass/fail
Sandboxing means you can hand this to a teammate — or an agent — without worrying what paths or env vars it can touch
quick_test skips the YAML entirely when you just need to hit an endpoint a few times right now

Usage in practice: before every deploy, someone on the team runs the same smoke test by hand. Wired up here, that becomes "run the api-smoke baseline and compare it to last week's." The agent replays the saved config, parses the JSON results into percentiles and error counts, and tells you plainly whether anything regressed — no spreadsheet required.

Eleven tools, split across running tests and managing saved configurations:

Tool	Parameters	Notes
`run_test_from_file`	`path`, `outputJson?`, `reportHtml?`, `env?`, `cwd?`, `validateOnly?`	Runs a config file already inside the workdir
`run_test_inline`	`configText`, `outputJson?`, `reportHtml?`, `env?`, `cwd?`, `validateOnly?`	Config as a YAML/JSON string — Artillery 2.0+ requires `flow:` instead of `requests:` in scenarios
`quick_test`	`target`, `rate?`, `duration?`, `count?`, `method?`, `headers?`, `body?`, `insecure?`, `keepResults?`, `outputJson?`	No config file needed; generates a one-request scenario
`run_saved_config`	`name`, `outputJson?`, `reportHtml?`, `env?`, `validateOnly?`	Runs a previously saved config by name
`save_config`	`name`, `content`, `description?`, `tags?`	Stores under `$ARTILLERY_WORKDIR/saved-configs/`
`list_configs`	`tag?`	Lists saved configs, optionally filtered by tag
`get_config`	`name`	Retrieves a saved config's content
`delete_config`	`name`	Deletes a saved config
`parse_results`	`jsonPath`	Summarizes a results file: RPS, latency percentiles (p50/p95/p99), HTTP codes, error counts, vuser stats
`list_results`	`limit?` (default 100)	Lists result files under the workdir, newest first
`list_capabilities`	(none)	Reports Artillery version, server version, transports, and configured limits

Note on HTML reports: recent Artillery releases removed the report command; if reportHtml is set and no file appears, the server falls back to returning the JSON path with a warning rather than failing outright.

Good for: quick load checks and baseline-vs-current regression comparisons, driven entirely from chat.

4. Observability & evidence

4.1 Dynatrace MCP

Repo: dynatrace-oss/dynatrace-mcp · Language: TypeScript · License: MIT
Status: 🔵 community, verified — source read and tool contract reviewed for this catalog.
Runtime: Node.js 24+ · npm package @dynatrace-oss/dynatrace-mcp-server · stdio by default, or --http for an HTTP/bearer-token mode Config: DT_ENVIRONMENT (required — the Platform URL, …apps.dynatrace.com, not the classic …live.dynatrace.com), DT_PLATFORM_TOKEN or OAUTH_CLIENT_ID/OAUTH_CLIENT_SECRET (optional — otherwise browser OAuth + OS keychain), DT_GRAIL_QUERY_BUDGET_GB (default 1000), DT_SSO_URL (optional override)

DQL is powerful and genuinely has a learning curve; the natural-language generate/verify/explain tools exist specifically so you don't have to memorize it to get an answer out of Grail.

Benefits:

generate_dql_from_natural_language + verify_dql means you get a query you can actually read before it runs against your data
The Grail budget (DT_GRAIL_QUERY_BUDGET_GB) turns "oops, that scanned way more than I meant" from a bill into a warning
Davis AI (chat_with_davis_copilot) is there for the "what does this actually mean" follow-up question a raw query result can't answer

Usage in practice: "during the checkout load test window, latency spiked — what happened?" resolves the service, generates and verifies a DQL query scoped to just that window, and cross-references list_problems and list_exceptions for the same period — landing on a concrete, correlated answer instead of a wall of log lines.

Capabilities are grouped by function (the README doesn't present them as a flat numbered list, but these are every tool named in the source docs):

Group	Tools
Observability & problems	`list_problems` · `list_vulnerabilities` · `list_exceptions` · `get_kubernetes_events`
Grail queries	`execute_dql` · `verify_dql` · `generate_dql_from_natural_language` · `explain_dql_in_natural_language`
Entity discovery	`find_entity_by_name`
Davis AI	`chat_with_davis_copilot` · `list_davis_analyzers` · `execute_davis_analyzer`
Automation & sharing	`send_slack_message` · `send_email` · `send_event` · `create_dynatrace_notebook`

Cost matters here: execute_dql scans Grail storage, billed by volume scanned. The server tracks usage against DT_GRAIL_QUERY_BUDGET_GB per session and warns at 80% of budget. You can audit actual consumption with a DQL query against dt.system.events filtered to client.client_context containing "dynatrace-mcp".

Required OAuth scopes vary by tool — at minimum app-engine:apps:run for nearly everything, plus the specific storage:*:read scope for whatever Grail data type you're querying (logs, metrics, spans, entities, events, etc.), davis-copilot:*:execute for the AI features, and email:emails:send / document:documents:* for the sharing tools.

Good for: correlating a load-test window with production problems and exceptions via DQL — the worked example in the companion post walks through exactly this.

4.2 Splunk MCP

Repo: livehybrid/splunk-mcp · Language: Python
Status: 🔵 community, verified — source read and tool contract reviewed for this catalog.
Runtime: Python, built on FastMCP · three operating modes: SSE (default), REST API (python splunk_mcp.py api), or stdio (python splunk_mcp.py stdio)
Config: SPLUNK_HOST, SPLUNK_PORT (default 8089), SPLUNK_TOKEN (or SPLUNK_USERNAME + SPLUNK_PASSWORD), SPLUNK_SCHEME (default https), VERIFY_SSL (default true), FASTMCP_LOG_LEVEL

Understanding the server's shape is exactly what lets you evaluate a Splunk MCP integration with open eyes instead of starting from zero.

Benefits:

Consistent error handling across every tool means a failed search or a permissions issue comes back as something you can actually act on, not a stack trace
The KV Store tools double as a lightweight state store for automation, a nice trick if you're already scripting around Splunk
Three transport modes (SSE, REST API, stdio) mean it can fit into however your team's tooling already talks to services

Usage in practice: during an incident, "search the last 30 minutes for checkout errors and summarize the affected sourcetypes" runs search_splunk scoped to that window, cross-references indexes_and_sourcetypes to explain where the noise is coming from, and gives you a triage-ready summary instead of a raw search-results table.

Thirteen tools across five functional groups:

Group	Tools
Meta	`list_tools`
Health	`health_check` (lists reachable Splunk apps) · `ping`
Users	`current_user` · `list_users`
Indexes	`list_indexes` · `get_index_info` (params: `index_name`) · `indexes_and_sourcetypes`
Search	`search_splunk` (params: `search_query`, `earliest_time?`, `latest_time?`, `max_results?`) · `list_saved_searches`
KV Store	`list_kvstore_collections` · `create_kvstore_collection` (params: `collection_name`) · `delete_kvstore_collection` (params: `collection_name`)

Error handling is consistent across the tool set: invalid searches, permission failures, missing resources, and bad input all return a structured error message rather than a bare exception.

Good for: understanding the pattern (search + index introspection + KV store) if you're evaluating whether to build against Splunk's now-official server instead.

5. Resilience & chaos

5.1 LitmusChaos MCP

Repo: litmuschaos/litmus-mcp-server · Language: Go · Status: 🟢 vendor-maintained (LitmusChaos project)
Runtime: connects to a running LitmusChaos ChaosCenter (3.x) over its GraphQL API
Config: CHAOS_CENTER_ENDPOINT, LITMUS_PROJECT_ID, LITMUS_ACCESS_TOKEN, optional DEFAULT_INFRA_ID, optional DEFAULT_ENVIRONMENT_ID

Chaos engineering has a well-earned reputation as YAML archaeology — CRDs, manifests, and infrastructure wiring before you even get to break anything on purpose. This collapses all of that into a sentence.

Benefits:

Sixteen tools cover the supported lifecycle, from discovering faults in a ChaosHub to registering infrastructure to reading back a resiliency score — you're not stitching together kubectl commands by hand
Resiliency scoring gives you a number you can actually track release over release, not just a pass/fail
It plugs into existing ChaosHub content, so you're not authoring fault definitions from scratch every time

Usage in practice: before a release, "run a pod-delete on checkout-service in staging for 30 seconds and tell me the resiliency score" starts the experiment, polls its status, checks the probes attached to it, and reports back a number and a verdict — the entire chaos-engineering loop, in one exchange.

The LitmusChaos server exposes 16 tools grouped into six functional areas:

Group	Tools (by function)
Chaos experiments	list experiments · get experiment details · run an experiment · stop an experiment
Execution monitoring	list runs · get run details
Infrastructure	list registered infrastructure · get infrastructure details · register new infrastructure
Environments	create an environment · list environments
Resilience probes	list probes · create supported probes
ChaosHub & statistics	list ChaosHubs · get fault details · review experiment statistics

Target infrastructure is Kubernetes/OpenShift; target applications are typically microservices, databases, APIs, and messaging systems. Repository layout for the server itself: main.go (server setup), handlers.go (tool handlers), go.mod, a Dockerfile, and a Makefile.

Good for: "run a pod-delete on the checkout service for 30 seconds and tell me the resiliency score" — the whole point of chaos engineering, minus the YAML and CRDs.

6. Front-end / client-side testing

6.1 Chrome DevTools MCP

Repo: ChromeDevTools/chrome-devtools-mcp · Language: TypeScript · Status: 🟢 vendor-maintained (the Google Chrome DevTools team)
Runtime: Node.js LTS, current stable Chrome · install via npx -y chrome-devtools-mcp@latest
Config: --headless, --isolated, --slim (basic-only tool set), --no-performance-crux (disable CrUX lookups), --no-usage-statistics or CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS (opt out of telemetry), CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS
Auth: none — it drives a local (or connected) Chrome instance directly via Puppeteer

This is the biggest tool surface in the whole catalog — 58 tools at the time of writing — because it isn't just a performance tool, it's the entire DevTools panel exposed to an agent: Performance, Network, Elements, Memory profiling, even PWA install/launch and browser extension management.

Benefits:

Real Chrome performance traces (performance_start_trace / performance_stop_trace / performance_analyze_insight) give you actual Core Web Vitals data, not an estimate
lighthouse_audit covers accessibility, SEO, best practices, and "agentic browsing" in the same session as your performance trace — one browser, one context, several kinds of evidence
The accessibility-tree snapshot (take_snapshot) lets an agent click, fill, and navigate a real page reliably, without brittle pixel coordinates
Ships from the same team that builds DevTools itself, so it tracks Chrome's actual internals rather than reverse-engineering them

Usage in practice: "check the performance of the checkout page and tell me what's hurting LCP" navigates to the page, starts a trace with performance_start_trace (reload enabled), stops it, and calls performance_analyze_insight for the specific insight — usually something concrete like render-blocking CSS or an oversized hero image, backed by the same trace data you'd get by hand in DevTools.

The full reference lists all 58 tools; the groups most relevant to performance and front-end testing:

Group	Tool count	Examples
Performance	3	`performance_start_trace`, `performance_stop_trace`, `performance_analyze_insight`
Network	2	`list_network_requests`, `get_network_request`
Debugging	9	`lighthouse_audit`, `take_snapshot`, `take_screenshot`, `evaluate_script`, `get_css_styles`
Navigation automation	6	`navigate_page`, `new_page`, `wait_for`, `list_pages`
Input automation	10	`click`, `fill`, `fill_form`, `hover`, `press_key`, `upload_file`
Emulation	2	`emulate` (viewport, network throttling, dark mode), `resize_page`
Memory	13	heap snapshot capture, comparison, and querying
Extensions, third-party tools, WebMCP, PWA	13 combined	browser extension and installed-app management

Good for: the same "audit this page" job as Lighthouse MCP, but backed by real trace data and the option to drive the page first (log in, add items to a cart, then trace the checkout flow) instead of only auditing a cold page load. Use --slim if you want the input/navigation/debugging basics without the full 58-tool surface.

6.2 Lighthouse MCP

Repo: priyankark/lighthouse-mcp · Language: TypeScript · Status: 🔵 community
Runtime: Node.js 22.19+, Chrome/Chromium (sandboxed) · install via MCP Registry, npx lighthouse-mcp, or global npm
Config: AUDIT_ALLOW_LOOPBACK (default true; set false for hosted/public-only audits)

Next to Chrome DevTools MCP's 58 tools at the time of writing, it's genuinely refreshing that this one only has two — sometimes you just want a score, not a workflow.

Benefits:

SSRF and DNS-rebinding protections are on by default, so it's safe to expose this to a shared bot or a hosted worker
Fast enough to run on every pull request without anyone noticing the extra time
Mobile-first defaults, which matches where most real users actually are

Usage in practice: a PR touching the checkout page triggers "audit this page on mobile and tell me the top fixes." run_audit comes back with a score and a category breakdown; if all you need is the headline number, get_performance_score skips the rest of the audit and answers in a fraction of the time.

Deliberately minimal — two tools, both wrapping Google Lighthouse directly:

Tool	Parameters	Notes
`run_audit`	`url`, `categories?` (`performance`, `accessibility`, `best-practices`, `seo` — default all), `device?` (`mobile` default \	`desktop`), `throttling?` (default true)
`get_performance_score`	`url`, `device?`	Performance score only — faster than a full audit

Safety model, worth calling out explicitly: Chrome runs sandboxed; loopback/private/link-local/ cloud-metadata destinations are blocked by default (redirects included) to prevent SSRF and DNS rebinding; audits are serialized one-at-a-time with a 120-second timeout; Chrome and the audit proxy are torn down after every run, success or failure.

Good for: a fast "what's wrong with this page" check when the worker's network and URL policies are configured appropriately.

6.3 PageSpeed Insights MCP

Repo: ruslanlap/pagespeed-insights-mcp · Language: TypeScript · Status: 🔵 community
Runtime: Node.js 20.19+ · npx -y pagespeed-insights-mcp, npm global, or Docker
Config: GOOGLE_API_KEY (with the PageSpeed Insights API enabled in Google Cloud Console)

Lighthouse alone tells only part of the story — it's a lab measurement over a throttled connection, which is pessimistic by design. PageSpeed adds the real-user CrUX data that says what's actually happening in production, so the two together stop you from either overreacting to a lab number or ignoring a real regression.

Benefits:

Lab and field data live behind one conversational interface instead of two separate dashboards
Built-in baseline comparison means "did the release regress?" is a single tool call, not a manual diff
Batch analysis triages up to ten pages at once, which matters the moment you're auditing more than a homepage

Usage in practice: after a release, "compare mobile performance of the old and new build and prioritize the fixes" runs pagespeed_analyze_page against both, pulls pagespeed_get_field_data for the real-user view, and hands back a ranked list — usually something unglamorous like an unoptimized hero image or a blocking third-party script.

Version 2 of this server deliberately replaced 19 endpoint-shaped tools with six workflow tools — worth knowing if you find v1 examples online, since the old tool names no longer exist.

Tool	Key parameters	What it covers
`pagespeed_analyze_page`	`url`, `strategy` (mobile/desktop), `report` (`full` \	`summary` \
`pagespeed_diagnose_page`	`url`, `focus` (`visual` \	`elements` \
`pagespeed_get_field_data`	`url` or origin, `scope` (`page` \	`origin`)
`pagespeed_compare_pages`	two URLs, or one URL + `mode: baseline`	Page-vs-page or page-vs-saved-baseline comparison
`pagespeed_analyze_batch`	1–10 URLs	Triage many pages at once, with progress notifications where the client supports it
`pagespeed_clear_cache`	(none)	Clears the in-memory API-response cache (useful right after a deploy)

Every data-returning tool accepts responseFormat: markdown (default) or json, and results come back as structured MCP structuredContent, not just prose.

Good for: combining lab results (Lighthouse, throttled and therefore pessimistic) with field results (CrUX, what real visitors experienced) in the same conversation — the README's own example shows GitHub.com scoring 54/100 in the lab while CrUX shows real users seeing a 1.9s FCP, which is a good illustration of why you want both.

7. Automation

7.1 Playwright MCP

Repo: microsoft/playwright-mcp · Language: TypeScript · Status: 🟢 vendor-maintained (Microsoft) — source lives in the main Playwright monorepo
Runtime: Node.js 18+ · install via npx @playwright/mcp@latest
Config: --browser (chrome/firefox/webkit/msedge), --headless, --isolated (fresh profile per session) or persistent profile (default), --device / --mobile emulation, --caps vision,pdf,devtools for optional extra capabilities, --cdp-endpoint to attach to an already-running browser, --allowed-origins / --blocked-origins for network scoping
Auth: none by default — trust boundaries are enforced through --allowed-origins/--blocked-origins and the workspace-root file-access restriction, not credentials

This is also the browser automation server used by the LoadRunner Agent framework described in this series: the lr-record-auto and lr-record-manual skills drive Playwright MCP to record a real UI journey, and lr-generate-har replays it headlessly to produce the HAR that feeds LoadRunner UI Vuser script generation. If you're already scripting browser automation for that pipeline, this is the same tool — you don't need a second one for general-purpose browser automation.

Benefits:

Works off the accessibility tree by default, not screenshots — faster, more deterministic, and it doesn't need a vision-capable model
--isolated sessions give you a clean-slate browser for every recording, so cookies and login state from a previous run can't leak into the next one
--cdp-endpoint lets you attach to a browser you already launched — useful for recording against a real, already-authenticated session instead of automating a fresh login every time
The same server doubles as your UI-automation recorder and your day-to-day "go check this page for me" browser agent — one integration, two jobs

Usage in practice: ask it to "log into staging, add an item to the cart, and go to checkout" and it takes a snapshot of the page, clicks and fills using the accessibility tree, and can hand that journey off as the seed for a LoadRunner Web Vuser script — the exact loop this repo's lr-record-auto skill automates end to end.

How a browser recording becomes a performance-test flow

Playwright MCP does not turn one browser session into a finished load test by itself. It records the business journey — the navigation, clicks, form submissions, waits, and resulting network activity — then a performance-testing tool converts that evidence into a script that can run many virtual users.

The practical handoff looks like this:

Record the journey. Ask the agent to drive a realistic flow, such as signing in, searching for a product, adding it to the cart, and checking out. Playwright MCP uses accessibility-tree actions such as browser_navigate, browser_click, and browser_type, so the recording follows user intent rather than screen coordinates.
Capture the network evidence. The recording pipeline observes the requests produced by that journey and saves them as a HAR (HTTP Archive). The HAR contains URLs, methods, headers, cookies, request bodies, responses, and timing details that a script generator can use as its input.
Generate the performance script. A converter such as this repository's lr-generate-har skill replays the journey headlessly and produces a HAR for LoadRunner UI Vuser script generation. The result is a repeatable protocol script, not another Playwright automation session.
Prepare it for load. Correlate dynamic values such as tokens and session IDs, parameterize user data, remove one-user-only steps, and add transactions, rendezvous points, checks, pacing, and load-model settings. These are performance-test decisions; they cannot be inferred safely from a single recording.
Validate at low load, then scale. Run one or a few virtual users first, confirm that the generated flow reaches the intended business state, and only then run the broader test while collecting latency, throughput, error, and resource evidence.

That makes Playwright MCP useful as a journey recorder and script seed: it captures the path a real user takes, while LoadRunner or another load engine supplies virtual-user concurrency, scheduling, measurements, and performance analysis. The recording is not automatically production-ready; authentication, test data, dynamic-value correlation, and traffic volume still need review.

Category	Representative tools	Notes
Navigation & interaction	`browser_navigate`, `browser_click`, `browser_type`, `browser_hover`, `browser_press_key`, `browser_select_option`, `browser_drag`, `browser_file_upload`	Structured, accessibility-tree-driven actions
Inspection	`browser_snapshot`, `browser_take_screenshot`, `browser_console_messages`, `browser_network_requests`, `browser_evaluate`	Read the page state without guessing from pixels
Session & tabs	`browser_tabs`, `browser_wait_for`, `browser_resize`, `browser_close`, `browser_install`	Multi-tab and lifecycle management

The exact tool list ships with the server and is documented in full in its own reference — treat the names above as the stable, widely-referenced surface rather than an independently re-verified list from source in this pass, the same treatment given to BlazeMeter's tool names earlier.

Good for: the automation category exists because of this one server — general-purpose browser scripting that happens to be the same tool this repo's own UI-recording pipeline is built on, so wiring it in once covers both "record a user journey for load testing" and "go check something on this page for me."

8. Server comparison at a glance

Server	Category	Status	Language	Tool count	Transport
k6	Load & stress	🟢 vendor-maintained	Go	6	stdio / HTTP
BlazeMeter	Load & stress	🟢 vendor-maintained	Python	cloud workflows (vendor-documented)	stdio / HTTP
LoadRunner Cloud	Load & stress	🔵 community	JavaScript	9	stdio / SSE
Apache JMeter	Load & stress	🔵 community	TypeScript	8	stdio
Artillery	Load & stress	🔵 community	TypeScript	11	stdio
Dynatrace	Observability	🔵 community	TypeScript	16	stdio / HTTP
Splunk	Observability	🔵 community	Python	13	stdio / SSE / API
LitmusChaos	Resilience	🟢 vendor-maintained	Go	16	GraphQL-backed
Chrome DevTools MCP	Front-end	🟢 vendor-maintained	TypeScript	58	stdio
Lighthouse	Front-end	🔵 community	TypeScript	2	stdio
PageSpeed Insights	Front-end	🔵 community	TypeScript	6 (v2)	stdio
Playwright MCP	Automation	🟢 vendor-maintained	TypeScript	varies by enabled capabilities	stdio

140+ independently-catalogued tools across ten servers, plus two more (BlazeMeter, Playwright) with vendor-documented tool surfaces — twelve servers, five categories, and that's before anyone writes the agent layer on top of them.

9. What trips people up in practice

These are the specific things that cause a working integration to quietly break, not a generic best-practices list:

Discover the live tool surface. MCP clients can discover the tools exposed by a server at connection time. Use that discovery result as the source of truth for the version and configuration you have installed, and keep an explicit allow-list for workflows that depend on specific tools.
Old tool names stop working silently. PageSpeed Insights replaced 19 endpoint-shaped tools with 6 workflow tools in its v2 release. Any example referencing the old names (analyze_page_speed, get_recommendations, etc.) will fail against a current install — check the version before you copy a snippet.
Community tool surfaces need version checks. Dynatrace and Splunk expose useful contracts for investigation and automation, but verify the exact tool names and parameters against the version you install.
Cost-bearing tools need a budget before you use them, not after. execute_dql (Dynatrace) scans Grail storage by volume. Nothing stops a broad query across 90 days of data the first time someone asks a vague question — set the budget first.
Not every tool is safe to auto-run. Several servers mix read tools with ones that have real side effects — send_email, send_slack_message, create_kvstore_collection, delete_kvstore_collection. The tool schema itself won't tell you which is which; you have to decide that before wiring one up.
SSE and stdio aren't interchangeable. LoadRunner Cloud and Splunk both support multiple transports, but with different startup flags and, in Splunk's case, different default behavior per mode. Check the mode-specific section, not just the quickstart.
A single vendor-maintained server can have a much larger tool surface than its peers. Chrome DevTools MCP alone exposes 58 tools — the largest individual tool surface in this catalog. If your client loads every tool schema into context by default, use --slim or an explicit allow-list instead of eating that cost on every request.
Playwright's persistent profile is exclusive. Only one browser instance can use the default persistent profile at a time; running two MCP clients against the same workspace will conflict. Use --isolated or a distinct --user-data-dir for parallel sessions.

10. Production considerations

A short checklist worth running before any of these servers goes anywhere near a shared environment:

Pin tool names, don't trust discovery blindly. MCP's dynamic tool listing means a server operator can rename or remove a tool at any time. If your integration depends on a specific tool existing, maintain an explicit allow-list and fail loudly if it's missing, rather than silently adapting to whatever the server currently exposes.
Cap cost-bearing queries. Dynatrace exposes DT_GRAIL_QUERY_BUDGET_GB for exactly this reason — use it, and default to short timeframes (12–24h) rather than open-ended windows.
Gate side-effecting tools behind approval. Anything that sends a message, creates a resource, or deletes data should require an explicit human or policy-engine confirmation, the same way you'd gate a write-capable API call in any other system.
Verify auth scope requirements up front. Dynatrace alone has more than a dozen distinct OAuth scopes depending on which tools you use (storage:logs:read, storage:spans:read, davis-copilot:*:execute, and so on) — request only what the tools you actually use require.
Track server status over time. Community projects evolve quickly, so revisit this catalog's status column periodically rather than treating it as a one-time check.
Don't stand up a second browser-automation server. If a team already wires up Playwright MCP for UI-script generation (as this repo's LoadRunner Agent framework does), reuse that connection instead of adding Chrome DevTools MCP or a third browser tool for the same job — decide which one owns browser automation and route everything through it.

None of this — the tool names, the parameters, the trust tiers — matters on its own. What matters is what happens once one of these is wired into a Copilot agent with a clear job and a few guardrails: a lengthy investigation can turn into a short conversation, and a tool you'd otherwise have to look up becomes a capability your team just has. The companion posts in this series walk through exactly that wiring, with a full worked example against Dynatrace — the config, the agent instructions, and a real conversation, not just a table of tool names.

The MCP server is the capability layer; the agent is the reasoning and orchestration layer. The real engineering value appears when the two are combined with explicit tool ordering, context management, and guardrails. An MCP server exposes what can be done; the agent determines when and in what order to use it, while policy determines what requires approval.

Part 2 is coming — a follow-up post on building the actual GitHub Copilot custom agents that sit in front of these MCP servers: the agent files, the tool-order and guardrail decisions, and worked examples beyond Dynatrace.

11. Credits & references

Every project below is third-party open source. Thank you to the maintainers — please check each repository's license and current maintenance status before depending on it in production.

k6 — https://github.com/grafana/mcp-k6
BlazeMeter — https://github.com/Blazemeter/bzm-mcp
LoadRunner Cloud — https://github.com/pbandreddy/loadrunner-cloud-mcp-server
Apache JMeter — https://github.com/aravindksk7/Jmeter-MCP
Artillery — https://github.com/jch1887/artillery-mcp-server
Dynatrace — https://github.com/dynatrace-oss/dynatrace-mcp
Splunk — https://github.com/livehybrid/splunk-mcp
LitmusChaos — https://github.com/litmuschaos/litmus-mcp-server
Chrome DevTools MCP — https://github.com/ChromeDevTools/chrome-devtools-mcp
Lighthouse — https://github.com/priyankark/lighthouse-mcp
PageSpeed Insights — https://github.com/ruslanlap/pagespeed-insights-mcp
Playwright MCP — https://github.com/microsoft/playwright-mcp (source in microsoft/playwright)

This post is the reference you come back to when you're deciding which server to wire up next. Part 2 of this blog picks up from here and walks through building the Copilot agents themselves.

DEV Community: Kavin Arvind Ragavan

Build Your First GitHub Copilot Custom Agent: A Practical LoadRunner Example

Creating Custom Agents in GitHub Copilot

1. What a custom agent is

2. The four customization primitives

3. How the pieces fit together

4. Anatomy of an .agent.md file

5. Tool IDs: use the namespaced form

6. Skills: package domain knowledge on demand

7. The LoadRunner Agent design

Phase 1: EXTRACT

Phase 2: GENERATE

Phase 3: REVIEW

8. A practical agent body

A minimal starter set

9. Why one file in and one file out matters

Security and approval boundaries

10. Common pitfalls and fixes

Wrong tool IDs

The agent writes a helper script

Batch reads exhaust the context

A tool is disabled in the session

Output structure drifts

YAML changes appear to do nothing

11. A repository layout that scales

12. Design checklist

Smoke-test the agent before sharing it

13. The larger lesson

14. Quick reference

References

Creating a Custom Copilot Agent for Chaos Engineering Using LitmusChaos and MCP

Target Audience

The Agent Is the Product

Why Create a Custom Agent?

Custom Agent Structure

The Agent Skill

Tutorial: Create the Agent and Skill

1. Register the MCP Server

2. Create the Custom Agent

3. Add the Operational Skill

4. Select the Agent in Copilot Chat

5. Test the MCP Server Directly

Architecture

What the MCP Server Does

Experiment Coverage

Prerequisites

Install ChaosCenter

Register the Local Chaos Infrastructure

Connect the MCP Backend

Set Up a Local Validation Target

Create the Experiment

Select and Test the Custom Agent

Run Through the Custom Agent

Small Prompts for the Agent

Prompt 1: Check Readiness

Prompt 2: Check the Target

Prompt 3: List Experiments

Prompt 4: Inspect the Experiment

Prompt 5: Validate the Target

Prompt 6: Ask for a Preflight

Prompt 7: Request Execution

Prompt 8: Confirm Execution

Prompt 9: Check the Run

Prompt 10: Verify Recovery

Prompt 11: Investigate Failure

Prompt 12: Stop Safely

Prompt 13: Inspect Infrastructure

Prompt 14: Manage Environments

Prompt 15: Work With Resilience Probes

Prompt 16: Discover ChaosHubs and Faults

Prompt 17: Review Statistics

Prompt 18: Register Infrastructure

What Failed During the Build

Docker Desktop Kubernetes was unstable at 2 GB

Standalone MongoDB broke expected DNS

Helm retained a pending operation

Generated Argo labels were invalid

The first MCP run was queued and rejected

Keep Local Validation Repeatable

References and Useful Links

4. Anatomy of an `.agent.md` file