> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/testing-with-ai-coding-agents/other-coding-agents.md).

# Copilot, Gemini CLI, and Windsurf

Use Copilot in VS Code, Gemini CLI, or Windsurf to create repository tests, connect ContextQA MCP, and verify application results with clear ownership boundaries.

## Quick answer

Copilot in VS Code, Gemini CLI, and Windsurf can support an agent-assisted testing workflow: inspect the repository, select the right testing layer, write reviewed assertions, and execute approved commands. Their MCP configuration formats differ. Connect ContextQA using the matching client settings, verify authentication with a read-only call, then use the discovered tools for managed application tests. Keep local command results and remote execution evidence separate.

## Start with the repository, whichever agent you use

This guide uses a report-export permission change as a running example. A viewer may read a report; an administrator may request its export. The requirement concerns both the interface and the server. Hiding the export button alone would not prove that a viewer cannot invoke the endpoint.

You need an existing repository, its supported test runner, an approved local or staging application, and disposable viewer and administrator fixtures. If your client cannot run shell commands or access the required files, prepare the change with it and execute through your normal terminal or CI. Report that boundary explicitly.

Ask the agent to build this plan before editing:

| Requirement                            | Test layer                                 | Observable result                                                  |
| -------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------ |
| A viewer is not allowed to export      | Unit                                       | The permission function denies the viewer role                     |
| A viewer cannot bypass the interface   | Integration                                | The actual HTTP boundary rejects the request and creates no export |
| An administrator can export            | Integration or application functional test | A valid export with the expected contents is produced              |
| The interface communicates permissions | Browser                                    | Viewer and administrator see the appropriate controls and status   |

Do not assume that the agent's knowledge of your implementation defines the correct permission rule. Give it the rule independently, then use the code to locate the boundary that should enforce it.

```
Inspect our repository instructions and existing test commands.
For report export, the required behavior is:
- viewers can read a report but cannot create an export;
- administrators can export an authorized report;
- rejected requests must not create an export record.
Propose the smallest useful unit, integration, and browser checks.
Reuse existing fixtures. Identify any missing setup before editing.
Do not weaken authorization or replace assertions just to get green tests.
```

The [functional testing guide](/testing-with-ai-coding-agents/functional-testing.md) develops this decision-table approach. Use the [integration guide](/testing-with-ai-coding-agents/integration-testing.md) to distinguish a real service boundary from a mocked unit test.

## Connect Copilot in VS Code

VS Code uses a `servers` object in `.vscode/mcp.json`. Merge the following entry into the existing file instead of replacing other servers:

```json
{
  "servers": {
    "contextqa": {
      "type": "http",
      "url": "https://mcp.contextqa.com/mcp"
    }
  }
}
```

Alternatively, use **MCP: Add Server** from the Command Palette and choose the HTTP connection. Open the server controls to start the connection, complete the authentication flow offered by the client, and enable the relevant tools in the chat tool picker. Review workspace trust and organizational restrictions if the server is unavailable. The configuration above contains no access token and should not be expanded with a copied session credential.

VS Code also supports user-level configuration; choose it when you do not want this server in a shared repository. Its [MCP server guide](https://code.visualstudio.com/docs/agent-customization/mcp-servers) documents configuration, trust, and tool selection. Check the current UI in your installed version rather than assuming an extension or agent mode has every tool enabled.

For the local test task, give Copilot the changed files and test matrix. Review its proposed edits as a normal diff, run the targeted command, and then run the broader suite when the changed boundary warrants it. Use ContextQA separately for the approved application workflow described below.

## Connect Gemini CLI

Gemini CLI uses `httpUrl` for a Streamable HTTP MCP server. Add this entry to the `mcpServers` object in your user or project `settings.json`:

```json
{
  "mcpServers": {
    "contextqa": {
      "httpUrl": "https://mcp.contextqa.com/mcp"
    }
  }
}
```

User settings live at `~/.gemini/settings.json`; a repository can use `.gemini/settings.json`. Preserve existing configuration and avoid enabling blanket trust just to simplify a tutorial. In an interactive Gemini CLI session, inspect and authenticate the server:

```
/mcp list
/mcp auth contextqa
```

These are Gemini session commands, not shell commands. The shell command `gemini mcp list` can also inspect configured servers. Gemini's [MCP server documentation](https://geminicli.com/docs/tools/mcp-server/) distinguishes HTTP and SSE configuration and describes OAuth handling.

For a command-oriented workflow, ask Gemini to report the repository baseline command, the changed tests, and each exit code. Have it stop when a needed service or fixture is absent. “Could not run” is a useful result; replacing a real integration test with mocked calls silently would change what was tested.

## Connect Windsurf / Cascade

Open the MCP configuration through the Cascade panel's MCP controls and **Open MCP config file** action. Add the server to the existing `mcpServers` object:

```json
{
  "mcpServers": {
    "contextqa": {
      "serverUrl": "https://mcp.contextqa.com/mcp"
    }
  }
}
```

Refresh the server list, complete OAuth when prompted, and confirm that the tools are available. Use the application's configuration action instead of guessing a filesystem path: names and locations differ across installed versions, and the current vendor reference is published as [Cascade MCP configuration](https://docs.devin.ai/desktop/cascade/mcp). Team settings may restrict allowed servers or tools.

When testing in the editor, ask the agent to keep the permission decision table beside its proposed changes. Review changes to application logic separately from test changes. A broad repair that makes the test pass by granting viewers export access contradicts the requirement even if the test command succeeds.

## Verify the connection before creating anything

In any client, start with this prompt:

```
Inspect the connected ContextQA server and available tool schemas.
Use a read-only listing to confirm which workspace and test cases
I can access. Report authentication or missing-tool errors exactly.
Do not create, execute, update, or export tests yet.
```

Successful configuration alone does not establish that your account has the tools or permissions required for a particular workflow. If a client does not complete the server's authentication flow, use [MCP troubleshooting](/mcp-server/troubleshooting.md) and the client reference rather than inventing a token or disabling authentication.

## Create the ContextQA application check

After local tests establish the permission logic, use ContextQA to exercise the approved application behavior. Supply the staging URL, application build, synthetic report identifier, authorized test roles, and reset procedure. A hosted MCP server cannot automatically reach `localhost` on your laptop; use a reachable test deployment or your organization's approved private-network setup.

Ask the agent to find an existing relevant case and inspect its steps before creating a duplicate. Review a plan such as:

1. Start in a fresh viewer session, verify the active role and tenant, and open the synthetic report.
2. Verify the report is readable and the export action is unavailable as specified.
3. Verify the direct export request is denied through an appropriate supported API test or the repository integration test. Keep that evidence separate if it cannot be exercised in the browser case.
4. Start a separate fresh administrator session, verify its role and tenant, and request the export.
5. Verify the resulting artifact's expected contents, not just a success toast or file existence.
6. Remove only export IDs created by this test and restore fixture state, including after a failure. Preserve the original failure if cleanup also fails.

Create or update the reviewed case using the tools actually present in the manifest. Some tools generate and execute in one operation; inspect their side effects before calling them. After a run, retrieve the final verdict, step results, and available artifacts. Do not label missing permission or file-content checks as passed.

## Review results and avoid false confidence

Keep a result record for each execution surface:

| Surface                      | Required evidence                                               | Common false positive                                    |
| ---------------------------- | --------------------------------------------------------------- | -------------------------------------------------------- |
| Repository unit tests        | Command, exit code, specific boundary assertions                | Expected values calculated by the same code being tested |
| Repository integration tests | Real boundary, isolated state, response and side-effect checks  | Mocking the boundary the test claims to verify           |
| ContextQA application case   | Case and execution identifiers, verdict, relevant step evidence | Treating a completed job or generated case as a pass     |
| Exported framework tests     | Reviewed files, standalone run, seeded-defect failure           | Treating generated placeholders as equivalent assertions |

Preserve the first failing attempt and explain a repair before rerunning. A disposable known-defect check can show that an assertion detects the intended problem. Never make that check by weakening permissions in a shared deployment.

## Frequently asked questions

### Can I copy one MCP configuration into every client?

No. These examples deliberately use different keys: VS Code uses `servers`, Gemini uses `httpUrl`, and Cascade accepts `serverUrl`. Use your client's supported transport and authentication flow, and verify a read-only tool call after setup.

### Do I need to move all tests into ContextQA?

No. Keep existing repository tests and add managed application checks where useful. The [framework selection guide](/testing-with-ai-coding-agents/framework-selection.md) helps assign each requirement to an appropriate runner and boundary.

### Can the agent export the application checks into Playwright?

Use the export tool available in your workspace and review its actual output. A file manifest may need to be written locally by the client. AI verification placeholders, manual steps, fixtures, and credentials need explicit review; follow the [export and portability guide](/testing-with-ai-coding-agents/export-and-portability.md) before claiming standalone coverage.

## Next step

[Complete ContextQA MCP setup](/mcp-server/installation-and-setup.md) and try one workflow using the client you already have. For an evaluation involving role permissions, private environments, or export ownership, [book a ContextQA workflow demo](https://contextqa.com/book-a-demo/?utm_source=learning.contextqa.com\&utm_medium=referral\&utm_campaign=docs_demand_gen\&utm_content=other_coding_agents_testing).

Client configuration references reviewed September 25, 2026. Tool availability, authentication UI, and account policies can change; verify them in your installed client and connected workspace.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://learning.contextqa.com/testing-with-ai-coding-agents/other-coding-agents.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.