TestingOps.ai

Connection guides · Connection guide

VS Code, Cursor and TestingOps: test results and cases inside your editor

Add TestingOps to the MCP configuration of VS Code (GitHub Copilot) or Cursor, and the editor's agent can read failing cases and run evidence while you fix the code, check which cases a change reaches and keep cases in step with the code.

  • Connection guide
  • Setup guide
Request a demo VS Code: add MCP servers
Connection
Connection guide
Writes back
Depends on the access you grant
Last checked
7 Nov 2026

In short

VS Code & Cursor and TestingOps in short

Editors such as VS Code (GitHub Copilot) and Cursor can use TestingOps when the TestingOps MCP endpoint, which ends in /api/mcp/v1, is added to the editor's MCP configuration as an HTTP server with the header Authorization: Bearer <key>.

The editor's agent then calls TestingOps tools for runs, evidence, cases and change impact; TestingOps installs no extension.

Because the editor connects from the developer's machine, it can use a self-hosted TestingOps that is not on the internet, as long as that machine can reach it.

What it does

What it does for your testing

  1. 1

    The failure next to the code

    Input
    A failing case from the last run
    TestingOps
    Returns the failed steps, the result and the evidence the run captured: screenshots, video, logs and traces
    Output
    The actual failure in the editor while the fix is written
  2. 2

    Which cases a change reaches

    Input
    The file paths changed on a branch
    TestingOps
    Works out which test cases the change can reach and lists changed modules that no case reaches
    Output
    Cases to run before merging, and the gaps in plain sight
  3. 3

    Cases kept in step with the code

    Input
    A changed validation rule
    TestingOps
    Updates the case that has the same key, or creates a new one as a draft
    Output
    Draft cases that a tester reviews and approves

Step by step

How it works

  1. Create an access keyUnder Integrations → API & MCP → Access keys, create a key with Read only or Read and write access and an expiry. The key is shown once.
  2. Copy the Client configThe MCP server card's Client config snippet holds the endpoint and the Authorization: Bearer <key> header.
  3. Add it to the editorCursor reads the entry under mcpServers in its mcp.json. VS Code's mcp.json lists servers under servers, with the same type, url and headers.
  4. The editor's agent calls TestingOpsFrom then on the agent can read runs, evidence and cases, ask for impact analysis and, with a Read and write key, update cases and start runs.

Other editors with an HTTP MCP configuration, such as Windsurf, take the same address and header. The direction is editor to TestingOps; outside tools that TestingOps agents call are set up separately under Extra tools your agents may use (outgoing, over MCP).

Connect

Setup

  1. In TestingOps, open Integrations → API & MCP, create a key under Access keys with Read only or Read and write and an expiry, and copy it: it is not shown again.
  2. Copy the Client config snippet from the MCP server card; it contains the endpoint and the Authorization: Bearer <key> header.
  3. Cursor: add the entry to mcp.json under mcpServers. VS Code: add it to mcp.json under servers, keeping type, url and headers.
  4. Replace <key> with the key you created; the editor's agent can then call the TestingOps tools.
  5. Revoke the key under Access keys when it is no longer needed.

Documentation: VS Code: add MCP servers · VS Code: MCP configuration reference · Cursor: Model Context Protocol

Where you connect it in TestingOps: Integrations → API & MCP → Connection guides → VS Code & Cursor

Use cases

Use cases

Fix a failing case with its evidence at hand

Trigger
A developer picks up a case that failed in the last run
Uses
Run results and captured evidence: screenshots, video, logs and traces
Agent activity
The editor's agent reads the failed step and its evidence, then looks at the code that produced it
Result
A fix based on the recorded failure instead of a guess
Condition
A Read only key is enough

Pick the cases to run for a branch

Trigger
A branch changes several files before a merge
Uses
Impact analysis from the changed file paths
Agent activity
The agent asks TestingOps which cases the changes can reach and which changed modules no case reaches
Result
A short list of cases to run, with the unknown parts named
Condition
The answer is as good as the code knowledge TestingOps has for the project; paths it does not know are reported as gaps

Update a case with a behaviour change

Trigger
A developer changes a rule that existing cases check
Uses
Case update by key, or a new draft case
Agent activity
The agent updates the affected case or writes a new draft with steps and expected results
Result
Draft cases a tester approves before they count
Condition
Needs a Read and write key

Capabilities

Capabilities and limits

What is read

  • Run results, failed steps and captured evidence (screenshots, video, logs, traces)
  • Test cases, scenarios and their traceability
  • Impact analysis for a list of changed file paths
  • Defects and the project knowledge base

What is produced

  • Answers and edits by the editor's agent, based on TestingOps tool results
  • Impact lists with the changed modules that no case reaches

Where it can write

With a Read and write key: cases (new ones as drafts, existing ones updated by key), runs, defects and data sets. A Read only key cannot change anything.

How it connects

An HTTP MCP server in the editor's MCP configuration, using the TestingOps endpoint and an Authorization: Bearer <key> header

Account and permissions

  • An access key from Integrations → API & MCP → Access keys: Read only or Read and write, expiring after 30 days, 90 days, 180 days or 1 year
  • The key is shown once when it is created and acts as its owner, in one company
  • Editors that sign in instead of sending a key can use the consent page only when their sign-in returns to an https address or to 127.0.0.1

Limits

  • TestingOps sign-in refuses return addresses on http://localhost and custom app links; use a key when an editor's sign-in fails
  • VS Code's mcp.json uses a servers key where the snippet says mcpServers
  • Requests are rate-limited per key, 600 a minute by default
  • Tools only: no MCP resources or prompts, and no TestingOps editor extension

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A developer works on a checkout bug in Cursor. The editor's agent reads the latest run through TestingOps: the payment case fails at the step that applies a discount code, and the captured log shows an error response from the pricing API.

After the fix, the agent passes the changed file paths to TestingOps' impact analysis. It lists three cases that reach the pricing module and one changed module that no case reaches; the developer runs the three and leaves a note for the test team about the gap.

Frequently asked questions

Do we need a TestingOps extension?

No. TestingOps is added as an HTTP MCP server in the editor's own MCP configuration; the editor's agent then lists and calls its tools.

Why does the snippet not paste as is into VS Code?

The Client config snippet uses mcpServers, the format Cursor reads. VS Code's mcp.json lists servers under servers: keep the inner entry with type, url and headers and change the outer key.

Can the editor sign in instead of using a key?

Only if its sign-in returns to an https address or to 127.0.0.1. TestingOps refuses return addresses on http://localhost and custom app links, so an access key is the dependable route for editors.

Does it work with a self-hosted TestingOps?

Yes, as long as the developer's machine can reach it. The editor connects from that machine, not from a vendor's cloud.

What can a Read only key do?

Read cases, runs, evidence and defects, check for duplicate cases and run impact analysis. TestingOps refuses writes for that key on the server, not only in the editor.

Is there a limit on requests?

Yes. Requests are rate-limited per key, 600 a minute by default, which matters when an editor's agent works through many cases in a row.

Next step

Request a demo to see an editor's agent read a failing run and pick the cases to rerun through TestingOps.

Request a demoMore connection guides integrations