The TestVibe MCP server

testvibe mcp starts a stdio MCP server exposing the current operation catalog as tools. It ships inside the CLI package and talks to the same REST API with the same key — setup is in Connect your AI tools.

Tools

Tool	Purpose
list_projects / get_project	Projects in the workspace.
list_features / get_feature	Browse features.
create_feature / update_feature / delete_feature	Edit features.
generate_feature / wait_for_generation / get_generation_status / get_generation_log / cancel_generation	Drive AI test generation.
run_feature / run_suite / wait_for_run / get_run / diagnose_run / list_runs / get_run_artifacts	Run tests, read results, and diagnose failures.
list_load_tests / create_load_test / update_load_test / delete_load_test / run_load_test	Manage and dispatch load tests on the cloud load pool.
get_live_servers / list_error_groups / list_server_metrics	Read live server vitals, application errors, and per-run server metrics.
list_automations / get_automation / create_automation / update_automation / delete_automation / run_automation / list_automation_runs	Manage automations and fire them.
get_coverage / scan_coverage / list_coverage_runs / run_coverage	Read coverage, scan areas, run execution coverage.
list_plugins / install_plugin / remove_plugin / publish_plugin / unpublish_plugin	Manage the project's plugin catalog.
list_variables / set_variable / delete_variable / list_secrets / set_secret / delete_secret	Project variables and write-only secrets.
list_files / read_file / write_file / delete_file / list_configs	Project files and configurations.

Project scoping

Most tools are project-scoped: it takes an optional project argument (a public id) and falls back to the configured default (testvibe use, TESTVIBE_PROJECT, or .testvibe.json). Set a default so the model doesn't have to thread the id through every call.

Designed for agents

• Tool descriptions carry the workflow. generate_feature tells the model to follow up with wait_for_generation; run_feature points at wait_for_run — an agent can discover the dispatch → poll pattern from the schemas alone.
• wait_* tools poll from the local MCP process (3 s interval, default 120 s / max 170 s per call) so one tool call replaces a polling loop, while staying inside MCP client timeouts. Timing out cancels nothing — the model just calls the tool again.
• Errors are sentences. API failures surface the server's human-readable message, so the model can correct course ("This feature is already generating.").
• Tool annotations. Read-only tools carry readOnlyHint and irreversible ones (delete_feature, delete_file, delete_load_test) carry destructiveHint, so MCP clients can skip or require confirmation appropriately.
• diagnose_run collapses the fix loop. One call returns a failed run's failing tests, the Gherkin, the current stored source at the recorded spec paths, and artifact links — no get-run → read-file → artifacts round trips.

info

Guardrails are server-side. The MCP server adds no privileges: the write allowlist, generation locks, and workspace scoping are enforced by the API regardless of what a model asks for. See Conventions & errors.

Workspace-scoped tools are list_projects, get_credits, list_billing_history, list_credit_usage, and list_credit_usage_by_member. The table above highlights documented groups; it is not the entire catalog. Ask the MCP client to list tools (tools/list) for the installed version’s schemas. Additional tools include model discovery, feature groups/history, generation questions/sessions, source repositories, assets, trace analysis, load measurements, and the Assistant.