Integration

Runscope integration

Runscope (now BlazeMeter API Monitoring by Perforce) runs scheduled and on-demand API tests from cloud regions or private agents. Start a run of one test or of a whole bucket through its trigger URL (with environment, regions and initial variables), queue several runs with different variables, read run results down to each HTTP request and response, follow response-time metrics, and manage buckets, tests, test steps, test-specific and shared environments and run schedules; team members, integrations, agents and regions can be listed. Schedule editing (delete and recreate instead), environment deletion, step reordering, test revisions, request usage counts, custom notification emails, team global variables and secrets, and role, group, invitation and email-domain administration are not exposed, and the credentials stored in steps and environments are never returned. Authentication is an OAuth 2 access token sent as a Bearer token: creating an application in the Runscope account generates a personal access token.

Ask it in chat

Say what should happen.
The workflow builds itself.

When this happens, do that in Runscope.Built from the 36 Runscope tools below, on the connection you add once.

What you can do with Runscope

Each of these is one operation on one endpoint, available both as a workflow step and as a tool an AI agent can call on its own. Nothing bundles several operations into one action, so what a run did stays readable afterwards.

Most endpoints run on the free plan. A few, mainly the ones that publish on your behalf, need a paid plan.

Environment, 6 operations

  • create_shared_environmentCreate shared environmentPOSTCreates a shared environment in a bucket (at most 100 per bucket) and returns it.
  • create_test_environmentCreate test environmentPOSTCreates an environment that belongs to one test (at most 100 test-specific environments per bucket) and returns it.
  • list_shared_environmentsList shared environmentsGETLists the shared environments of a bucket, which any test of the bucket can run with or inherit from.
  • list_test_environmentsList test environmentsGETLists the environments that belong to one test (not the bucket's shared environments): initial variables, regions, agents, notification settings, webhooks and run options.
  • update_shared_environmentUpdate shared environmentPUTReplaces the settings of a shared environment. Send the full environment, not only the changed fields.
  • update_test_environmentUpdate test environmentPUTReplaces the settings of a test-specific environment. Send the full environment, not only the changed fields.

Step, 5 operations

  • add_test_stepAdd test stepPOSTAdds a step at the end of a test: an HTTP request, a pause, a condition, a Ghost Inspector run or a subtest.
  • delete_test_stepDelete test stepDELETEDeletes one step from a test.
  • get_test_result_stepGet test result stepGETReturns the HTTP request and response actually exchanged by one request step of a run: method, URL parts, headers and body sent, and status, headers, body.
  • list_test_stepsList test stepsGETLists the steps of a test in execution order: HTTP requests with their assertions, variables and scripts, pauses, conditions, Ghost Inspector and subtest steps.
  • update_test_stepUpdate test stepPUTReplaces the settings of one step of a test (same body as add_test_step) and returns the updated step.

Test, 5 operations

  • create_testCreate testPOSTCreates a test in a bucket.
  • delete_testDelete testDELETEDeletes a test with all its steps, schedules, test-specific environments and results.
  • get_testGet testGETReturns one test in full: its steps in order (with assertions and variables), its environments, its schedules, its trigger URL, its creator and a summary of its last run.
  • list_testsList testsGETLists the tests of a bucket with their id, name, trigger URL, step count, usage and a summary of the last run. Environments and schedules are not included: use get_test.
  • update_testUpdate testPUTChanges a test's name, description, default environment or steps; fields left out are not modified. Environments and schedules are changed through their own tools.

Bucket, 4 operations

  • create_bucketCreate bucketPOSTCreates a bucket in a team and returns it with its key.
  • delete_bucketDelete bucketDELETEDeletes a bucket. The default bucket of an account cannot be deleted.
  • get_bucketGet bucketGETReturns one bucket: name, key, team, creation time, privacy, test count, custom notification emails and the bucket's trigger URL (runs every test of the bucket).
  • list_bucketsList bucketsGETLists the buckets (containers of tests) the account can access, with their key, name, team and settings.

Result, 3 operations

  • get_test_resultGet test resultGETReturns one run of a test in full: overall result (pass, fail, working, canceled or queued), every request step with its URL, method, assertions, variables, scripts and timings.
  • list_bucket_resultsList bucket resultsGETLists the bucket-level runs of a bucket (all its tests run at once from the bucket trigger or Run All): status, result, duration and pass counts of test runs, requests.
  • list_test_resultsList test resultsGETLists the runs of a test, finished and in progress: result (pass, fail, working, canceled or queued), timings, region, environment and counts of passed and failed assertions.

Schedule, 3 operations

  • create_test_scheduleCreate test schedulePOSTSchedules a test to run on an interval with one environment, and returns the new schedule.
  • delete_test_scheduleDelete test scheduleDELETEDeletes (stops) one schedule of a test.
  • list_test_schedulesList test schedulesGETLists the schedules of a test: interval, environment used and note.

Trigger, 2 operations

  • trigger_bucketTrigger bucketGETStarts a run of every test in a bucket now (like Run All) and returns the queued runs with their test_run_id. Only a shared environment can be chosen.
  • trigger_testTrigger testGETStarts a run of one test now and returns the queued runs with their test_run_id (read the outcome with get_test_result).

Account, 1 operation

  • get_accountGet accountGETReturns the authorized account: name, uuid, email (only with the account:email scope) and the teams it belongs to, each with its uuid and name.

Agent, 1 operation

  • list_team_agentsList team agentsGETLists the team's currently connected remote agents with their agent_id, name, version and host details.

Batch, 1 operation

  • batch_trigger_testBatch trigger testPOSTQueues up to 50 runs of one test at once, one per set of initial variables, and returns the queued runs.

Integration, 1 operation

  • list_team_integrationsList team integrationsGETLists the third-party services connected to a team (PagerDuty, Slack and others), each with its uuid, type and description.

Latest, 1 operation

  • get_latest_test_resultGet latest test resultGETReturns the most recent run of a test in full: overall result, every request step with its URL, method, assertions, variables, scripts and timings, and subtest details.

Metric, 1 operation

  • get_test_metricsGet test metricsGETReturns the dashboard metrics of a test over an hour, day, week or month: average response time and success ratio per interval, the 50th, 95th and 99th percentile response times.

Person, 1 operation

  • list_team_membersList team membersGETLists the people of a team with their name, uuid, email, role and last login date. Page through large teams with count (at most 200) and page, until data comes back empty.

Region, 1 operation

  • list_regionsList regionsGETLists the service regions tests can run from, with the region_code to use in environment regions and trigger runscope_region, and their location and provider.

Use Runscope from Claude Code, Cursor or Codex

Connect Runscope in LiveContext, create an API key in Settings, then add the LiveContext MCP server to your client. Its Runscope operations become tools the client can call, next to every other integration you connected.

Claude Code
claude mcp add --transport http livecontext https://livecontext.ai/mcp --header "X-API-Key: YOUR_API_KEY"
Codex (~/.codex/config.toml)
[mcp_servers.livecontext]
url = "https://livecontext.ai/mcp"

[mcp_servers.livecontext.http_headers]
"X-API-Key" = "YOUR_API_KEY"
Cursor, Claude Desktop and other JSON configs
{
  "mcpServers": {
    "livecontext": {
      "type": "http",
      "url": "https://livecontext.ai/mcp",
      "headers": {
        "X-API-Key": "YOUR_API_KEY"
      }
    }
  }
}

Set up the MCP server step by step

How to connect Runscope

  1. Create your workspace

    Sign up free. Nothing to install.

  2. Connect Runscope once

    Add your Runscope connection in Settings. Every tool from this integration reuses it, and secrets are encrypted at rest and visible only to you.

  3. Describe the job in chat

    The workflow builds itself in front of you and picks the endpoints it needs. Drag the steps yourself on the canvas whenever you would rather be explicit.

Runscope integration FAQ

What can you do with the Runscope integration?

LiveContext exposes 36 operations on Runscope, covering environment, step, test and bucket.

Popular integrations

Browse the whole catalog