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:
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 develops this decision-table approach. Use the integration guide 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:
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 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:
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:
These are Gemini session commands, not shell commands. The shell command gemini mcp list can also inspect configured servers. Gemini's MCP server documentation 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:
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. 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:
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 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:
Start in a fresh viewer session, verify the active role and tenant, and open the synthetic report.
Verify the report is readable and the export action is unavailable as specified.
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.
Start a separate fresh administrator session, verify its role and tenant, and request the export.
Verify the resulting artifact's expected contents, not just a success toast or file existence.
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:
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 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 before claiming standalone coverage.
Next step
Complete ContextQA MCP setup 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.
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.
Last updated
Was this helpful?