
June 20, 2026

TestInspector MCP tokens are authentication credentials that connect AI coding environments — Claude Code, Cursor, and Claude Desktop — to your TestInspector account via the Model Context Protocol. Once connected, you can describe a test scenario in plain language and the AI generates structured test steps, executes existing tests, and retrieves run results without leaving the coding environment. The token grants the AI tool scoped access to your TestInspector organization so test management becomes a conversation rather than a context switch.
The Model Context Protocol is an open standard that allows AI assistant tools to call external APIs through a structured tool-definition layer. An MCP server defines a set of actions — create a test, list suites, trigger a run — and exposes them to the AI in a way the model can invoke with the right parameters. The AI does not browse the web or guess at API shapes; it calls specifically defined operations using credentials the user has provisioned.
TestInspector generates per-organization MCP tokens from the settings panel. Each token is tied to a specific organization and carries the same permission scope as the member who generated it. Every action the AI takes through the MCP — creating a test, reading a suite, triggering a run — is authenticated and logged against the generating member's account.
The MCP server itself is a lightweight process that bridges the AI tool to TestInspector's API. In Claude Code and Cursor, MCP servers are configured via a JSON settings file that specifies the server executable and any required environment variables, including the token. Once configured, the tools defined by the TestInspector MCP server appear in the AI's available capabilities, and the model can call them as needed during a conversation.
Unlike browser-based automation or Selenium-style scripting, test definitions in TestInspector are structured step sequences — not code. When the AI generates a test through the MCP, it produces the same step format a user would create manually through the chat interface: navigation steps, input steps, assertion steps, HTTP request steps. The result is a test that runs via TestInspector's Selenium-backed runner across Chrome, Firefox, Edge, and Safari without any additional transformation. For more on building maintainable automation frameworks, see Astaqc's test automation services and the AI in software testing guide.
Claude Code is Anthropic's CLI-based AI coding assistant that runs in the terminal and integrates with VS Code, JetBrains, and other editors. It supports MCP servers through a configuration file at ~/.claude/settings.json (global) or a project-level .claude/settings.json. Adding the TestInspector MCP server requires an entry under the mcpServers key that specifies the server command and the MCP token as an environment variable.
Once configured and Claude Code is restarted, the TestInspector tools are available in the session. You can ask Claude Code to list your test suites, describe a user flow you want covered, and the model will construct the test steps and call the create-test tool directly. The test appears in your TestInspector organization immediately, ready to run or edit through the normal interface.
Claude Code's tool-use model means the AI decides which MCP tools to call based on your natural language input. If you describe a checkout flow and ask for test coverage, Claude Code will generate the steps, call the MCP to create the test in the right suite, and report back the test ID and a link to the created test. If a step is ambiguous, Claude Code will ask for clarification before proceeding.
Project-level configuration is particularly useful for teams. Adding the TestInspector MCP server config to the project's .claude/settings.json means every developer who opens that project with Claude Code gets the TestInspector tools available automatically, using their own token stored locally. Test coverage can become part of the code review and pull request workflow rather than a separate post-development phase. For broader QA strategy that integrates automation tooling into development workflows, see Astaqc's software testing services.
Cursor is an AI-enhanced code editor built on VS Code that supports MCP servers through its settings panel. The settings UI has a dedicated MCP servers section where you enter the server name, command, and environment variables through a form. The TestInspector token goes into the environment variables section as TESTINSPECTOR_TOKEN.
Once configured, the TestInspector MCP tools are available to Cursor's AI features: the chat panel, the Composer, and inline suggestions. In the Composer — Cursor's multi-file editing mode — you can ask for test coverage while reviewing a feature implementation, and Cursor will generate and create the tests in TestInspector alongside the code changes it proposes. This collapses the feedback loop between writing code and writing test coverage for that code.
Cursor's agent mode is well suited to test maintenance tasks via MCP. If a refactor changes the URL structure of a feature, you can ask Cursor to identify any existing TestInspector tests that reference the old URL and update them. Cursor will call the MCP to retrieve the affected tests, propose updated step definitions, and apply the changes through the MCP's update-test operation. The changes log against your account in TestInspector, so the audit trail is preserved.
Cursor and Claude Code use the same underlying MCP specification, so a TestInspector MCP server configured for one tool can be adopted in the other without changes to the server configuration. For teams evaluating whether AI-assisted test authoring fits their current workflow, the manual vs. automated testing guide provides a framework for assessing readiness and tradeoffs.
The TestInspector MCP server exposes the core test management operations as callable tools. The practical capabilities available through Claude Code or Cursor include creating a test from a natural language description of a user flow, listing suites and tests, retrieving existing test steps, triggering a run and getting the result, updating steps when a UI change requires maintenance, generating accessibility assertion steps using axe-core severity targeting, and adding HTTP request steps with assertion conditions.
| Task | Without MCP | With MCP via Claude Code/Cursor |
|---|---|---|
| Create a login test | Open TestInspector, chat to generate steps, save to suite | Describe the flow in the editor; AI creates the test via MCP |
| Check test status | Open TestInspector dashboard, navigate to suite | Ask the AI; it calls list-runs and returns status inline |
| Update a step after a UI change | Open test, locate step, edit selector or text | Describe the change; AI calls update-test with revised steps |
| Add an API assertion to a flow | Open test, add HTTP request step manually | Ask AI to add an HTTP step with endpoint and expected response |
| Generate accessibility checks | Open test, add accessibility assertion step, set severity | Ask AI to add axe-core assertions at error severity level |
The AI interface reduces context switching, but it does not replace the TestInspector UI for all operations. Complex test design decisions benefit from the direct interface where the full context of the test structure is visible. The MCP is most efficient for creation, retrieval, and straightforward maintenance tasks. For guidance on scaling test automation, see Astaqc's QA team service and the guide to outsourcing QA.
TestInspector also provides a CI/CD trigger API for running tests as part of a deployment pipeline. Both the CI API and the MCP token access TestInspector's backend, but they serve different purposes and are used in different contexts.
The CI/CD API is designed for automated pipeline execution: a deployment step calls the API endpoint, TestInspector runs the specified suite, and the pipeline receives a pass or fail result to gate the deployment. The API is called by machine processes — GitHub Actions steps, GitLab CI jobs, Jenkins pipelines — not by interactive AI tools.
MCP tokens are designed for interactive AI-assisted workflows: a developer or QA engineer working in Claude Code or Cursor asks the AI to perform test management tasks on demand. The scope of operations is broader — creating and editing tests, not only triggering them — because the context is interactive authoring rather than automated pipeline execution.
| Dimension | CI/CD API | MCP Token |
|---|---|---|
| Used by | Automated pipeline jobs | AI tools (Claude Code, Cursor, Claude Desktop) |
| Primary operations | Trigger run, get result | Create, read, update, trigger, get result |
| Authentication | CI API key | MCP token (per-organization, per-member) |
| Interaction model | Synchronous or async pipeline step | Conversational, AI-mediated |
| Use case | Deploy gate after merge | Test authoring and maintenance during development |
In a mature workflow, both integrations are in use simultaneously. The MCP token enables developers and QA engineers to create and maintain tests efficiently during feature development. The CI/CD API ensures those tests run automatically on every merge, providing the deployment gate that makes test coverage operationally meaningful. For organizations establishing a multi-layer QA integration strategy, Astaqc's test automation services provide implementation guidance. The software testing cost guide covers total cost modeling for tooling investments like TestInspector.
An MCP token carries the same permission scope as the organization member who generates it. An owner token grants access to all operations available to an owner; a member token is scoped to member-level operations. Generating a token from a member account rather than an owner account is the recommended approach when restricting AI tool access to authoring and retrieval only.
Yes. Each team member can generate their own MCP token from their account settings. All tokens belong to the same organization, so tests created by one member through Claude Code are visible to all other members in the organization. The token identifies which member performed which action in the audit log.
Yes. Claude Desktop supports MCP servers through a configuration file at a platform-specific path — on macOS, ~/Library/Application Support/Claude/claude_desktop_config.json; on Windows, the equivalent AppData path. The configuration format is identical to Claude Code's MCP server entry, giving the same TestInspector tools to the Claude Desktop chat interface.
Tests, suites, and run results created through the MCP persist in TestInspector after the token is revoked. Revoking a token removes the ability for the associated AI tool to make further API calls, but it does not delete or alter any content already created. Generating a new token and reconfiguring the MCP server restores full connectivity.
Variables marked as sensitive in TestInspector are encrypted at rest and are never returned in plain text through the API. The MCP server can reference sensitive variables by name in test steps, but the underlying encrypted value is not transmitted to or visible by the AI tool. The AI works with variable names as references, not with the resolved secret values.
TestInspector supports exporting test definitions to Playwright TypeScript, Selenium IDE (.side), and Gherkin format through the standard interface. Whether this export operation is exposed as an MCP tool depends on the version of the TestInspector MCP server package. See astaqc.com/test-inspector for the current list of available MCP operations.

Sign up to receive and connect to our newsletter