AI clients (MCP)

Testsnag speaks the Model Context Protocol (MCP), the standard AI coding assistants use to call outside tools. Connect one and you can ask it, in plain language, to write an API test for the endpoint you just built, run the checkout suite, or work out why last night's run failed. The assistant does the same things you would do in the dashboard: it reads and edits tests, starts runs, and reads the results.

Connecting your assistant

The AI clients tab in your workspace settings shows the server address and a ready-to-copy setup for each client. The address is the Testsnag address you sign in at, followed by /mcp. You do not need a token: the first time the client connects, it opens your browser so you can sign in.

Claude Code: run this once in a terminal.

claude mcp add --transport http testsnag https://testsnag.com/mcp

Codex: add the server, then sign in.

codex mcp add testsnag --url https://testsnag.com/mcp
codex mcp login testsnag

Cursor: add this to ~/.cursor/mcp.json, or to .cursor/mcp.json in a project.

{
    "mcpServers": {
        "testsnag": {
            "url": "https://testsnag.com/mcp"
        }
    }
}

VS Code: add this to .vscode/mcp.json in your project.

{
    "servers": {
        "testsnag": {
            "type": "http",
            "url": "https://testsnag.com/mcp"
        }
    }
}

Claude.ai, Claude Desktop and ChatGPT: in Claude, add Testsnag from the connector directory; in ChatGPT, add the server address as a custom MCP server. See Claude and ChatGPT for the steps.

Approving the connection

When the browser opens, sign in to Testsnag if you are not already, then choose which workspace the assistant can use and how much it can do:

• Read only: the assistant can look at tests, runs, suites and results, but cannot change anything or start a run. A good choice for asking questions about failures.
• Read and write: the assistant can also create and edit tests, start runs and change workspace settings your role allows.

Approve, and the browser sends you back to the client, which is now connected. The connection shows up on the API tokens tab of that workspace as a connected app.

Using an API token instead

Where no one is around to sign in through a browser, such as CI or a script, use a workspace API token. Create one in your workspace settings, on the API tokens tab, with the same Read only or Read and write access. It is shown once, so copy it then. Straight after you create it, the AI clients tab shows each setup with the token filled in. Every client sends it as a header, for example:

claude mcp add --transport http testsnag https://testsnag.com/mcp --header "Authorization: Bearer tsg_your_token"

How the assistant works with your tests

Most requests come down to the same loop, and the assistant is told to follow it:

1. 1

   Find or create the test

   It lists your tests, or creates a new one.

2. 2

   Write the steps

   It reads the step reference first, so it uses the same step types, assertions and {{variables}} you do.

3. 3

   Run it

   It starts a run and checks its status until it finishes.

4. 4

   Read the result and fix

   It reads the failed steps, fixes the test, and runs it again if needed.

Clients that support prompts also offer three ready-made ones: debug_failed_run, which investigates a run and proposes a fix, create_api_test, which builds an API test from a description, and create_web_test, which builds a browser test from a description and, in a coding tool such as Claude Code or Codex, from your app code.

For a web test, the assistant can also ask TestSnag to draft the steps: an AI opens your live site, works through what you asked for one step at a time, and adds every step that worked to the test. This is the best option in ChatGPT or Claude on the web, which cannot see your site or its code. Drafting does not use your run quota, and one draft runs at a time per workspace.

Finding the less common tools

The everyday tools (tests, runs, the workspace) are always loaded. Everything else, such as suites, blocks, scripts, variables, the mailbox, webhooks, integrations and members, sits in a searchable catalog so it does not crowd the assistant's context. The assistant finds them with search_tools and calls them with execute_tools, so you never need to name a tool yourself: just ask for what you want.

Shipping a mobile build

The assistant can do everything the command line tool does: upload a new iOS or Android build, attach it to several tests at once, and run them. Ask something like "upload ./app-release.apk, attach it to Checkout smoke and Sign up, then run both". It follows these steps:

1. 1

   Start the upload

   create_build_upload returns a private upload address that works for an hour, plus a ready curl command.

2. 2

   Send the file

   The assistant runs that command, so builds of any size go straight to storage without passing through the chat.

3. 3

   Confirm and attach

   complete_build_upload checks the file arrived, then bind_build_to_tests attaches it to every test you named, by id or by full name.

4. 4

   Run

   Once the build has published, run_test starts each test and get_run_status follows it to the end.

Environments

run_test, run_suite, and trigger_schedule_now take environment or environments, as an environment id, a name, a list, or all. With several, one run starts per environment and the quota check is all or nothing. The catalog also has list_environments, create_environment, update_environment, and delete_environment, and update_test_settings sets which environments a test may run in. Secret environment values are never returned. See Environments.

Passwords and secrets

The assistant can create secret variables and use them in steps as {{name}}, but it can never read their values back. Ask what a secret holds and it only learns that the secret exists and has a value. Anywhere a secret value would appear in a run result, the assistant sees [secret:name] instead.

This is deliberate. Pages and API responses from the site under test flow back to the assistant, and a hostile page could try to trick it into fetching your secrets and sending them elsewhere. With secrets write-only, there is nothing for it to give away. For the same reason, anything that comes back from the site or API under test is marked as data, so the assistant does not follow instructions hidden inside a page or response.