Hero demo prompt

The one-prompt end-to-end demo that proves the platform is MCP-ready. Drop this into Claude Desktop (with both the proofarc and github MCP servers configured) and watch Claude orchestrate everything.

The prompt

Explore the apps registered under the User Management Platform project on app.proofarc.ai. For each one, read the relevant source files via the GitHub MCP server, generate appropriate tests, run them in the development environment, and tell me what failed.

What Claude does

Notice every tool call uses names, not ids. The resolver does the lookups (with a per-session cache, so repeated references to the same project are free).

list_projects                                              ← proofarc MCP
list_project_applications(project="User Management Platform")
  ⇒ [User Service API (Spring Boot REST, authRequirement: AUTHENTICATED, swaggerPath: /v3/api-docs),
     User Service UI  (React WEB_APP,  authRequirement: AUTHENTICATED)]

# Branch 1 — REST API
github.search_files("@RestController")                     ← official GitHub MCP
github.get_file_contents("UserController.java")
create_api_scenario(
  name="[MCP] User Service CRUD",
  project="User Management Platform",
  environment="development",
  base_url="http://user-service:8089",
  auth_config={authType:BEARER, tokenSource:LOGIN_ENDPOINT,
               loginEndpoint:"/auth/login",
               credentialTag:"admin"},
  steps=[6 CRUD steps],
  tags=["mcp-demo", "smoke"])                              ← proofarc MCP
  ⇒ {id: 217, name: "[MCP] User Service CRUD", stepCount: 6}
execute_scenario(scenario="[MCP] User Service CRUD",
                 environment="development")                ← proofarc MCP
get_execution_status(execution_id="…", kind="api_scenario") ← polled

# Branch 2 — Web UI
run_ui_test(test="User signup happy path",
            environment="development",
            credential_tag="admin")
get_execution_status(execution_id="…", kind="ui_job")      ← polled

summarize_execution(execution_id="…", kind="api_scenario")
summarize_execution(execution_id="…", kind="ui_job")

Claude's final answer references both summaries and points the user at the saved tests on app.proofarc.ai so they can re-run them later via the UI, the REST API, or scheduled pipelines.

Demo flows for recording

Three short, named flows you can record back-to-back. Each is a single self-contained prompt to drop into Claude Desktop. Total runtime ~3 minutes.

Flow 1 — API scenario from Swagger (~30s)

Prompt:

Discover the swagger spec for the User Service API in the development environment, create an API scenario from it covering the user CRUD endpoints, run it, and summarize the result.

Tool sequence:

list_project_applications(project="User Management Platform")
  ⇒ swaggerPath="/v3/api-docs" on User Service API
resolve_swagger_url(application="User Service API", environment="development")
  ⇒ computedSwaggerUrl="http://user-service:8089/v3/api-docs", source="composed"
parse_swagger(url="http://user-service:8089/v3/api-docs")
create_scenario_from_swagger(
  project="User Management Platform",
  environment="development",
  url="http://user-service:8089/v3/api-docs",
  name="[MCP] Flow 1 — User CRUD",
  path_globs=["/api/users/**"],
  tags=["mcp-demo-flow-1"])
execute_scenario(scenario="[MCP] Flow 1 — User CRUD",
                 environment="development",
                 wait=true, summarize=true)
  ⇒ status, passed/failed counts, one-screen NL summary

Key capabilities shown: auto-discovery of swagger URL via the new resolve_swagger_url tool (release#107), endpoint filtering via path globs, one-call wait+summarize flow.

Flow 2 — Build a UI test from YAML (~60s)

Prompt:

Build a UI test for the User Service UI signup flow. Validate the YAML first, create the test with WebDriver as the driver, then run it in development and tell me how it went.

Tool sequence:

list_project_applications(project="User Management Platform")
  ⇒ User Service UI (WEB_APP, REACT)
discover_form_fields(url="http://user-service-ui/signup")
  ⇒ {fields: [{name, selector, required, ...}], submitButton: {…}}
validate_ui_test_yaml(yaml_text="""
  steps:
    - action: NAVIGATE
      value: "{{baseUrl}}/signup"
    - action: SEND_KEYS
      selector: "#email"
      value: "demo+{{randomSuffix}}@example.com"
    - action: CLICK
      selector: "button[type=submit]"
    - action: VALIDATE_TEXT
      selector: ".success"
      expectedText: "Welcome"
""")
  ⇒ {valid: true, stepCount: 4, warnings: []}
create_ui_test_from_yaml(
  name="[MCP] Flow 2 — Signup happy path",
  yaml_text=…,
  project="User Management Platform",
  driver="WEBDRIVER",
  tags=["mcp-demo-flow-2"])
  ⇒ {id: 117, name: "…", stepCount: 4}
run_ui_test(test="[MCP] Flow 2 — Signup happy path",
            environment="development",
            wait=true, summarize=true)
  ⇒ {jobId: "f4db…", status: "COMPLETED", summary: "…"}

Key capabilities shown: form auto-discovery, YAML validate-then-create (catches typos before the test even saves), wait+summarize returns human-ready output in one call.

Flow 3 — Suite across multiple engines (~90s)

Prompt:

Find the 'User Service UI Regression' suite and run it across both WebDriver and Playwright. Wait for all jobs and tell me which tests passed on which engine.

Tool sequence:

find_ui_test_suites(project="User Management Platform",
                    name_contains_text="Regression")
  ⇒ [{id: 4, name: "User Service UI Regression", testCount: 8}]
run_ui_test_suite(
  suite="User Service UI Regression",
  environment="development",
  drivers=["WEBDRIVER", "PLAYWRIGHT"],
  tag="mcp-demo-flow-3")
  ⇒ {executionGroupId: "…",
     jobs: [{jobId, driver, browser, testName}, ...]}     # 16 jobs (8 tests × 2 engines)

# Claude polls each jobId in parallel:
get_execution_status(execution_id="<jobId-1>", kind="ui_job")
get_execution_status(execution_id="<jobId-2>", kind="ui_job")
…
summarize_execution(execution_id="<jobId-N>", kind="ui_job")

Key capabilities shown: suite resolution by name with progressive narrowing, cross-engine fan-out (Cartesian of drivers × browsers), jobId UUID polling (with self-correcting error if you pair the wrong kind, release#142).

Flow 4 — Crawl + LLM-composed UI test (~60s) ★ release#156

Prompt (the demo headline):

Crawl https://store-qa.portnov.com/login. Read the element inventory, compose a UI test that logs in as admin and verifies the dashboard heading appears, validate it, then persist it in the User Management Platform project tagged mcp-demo-flow-4, and run it in development. Tell me which selectors you chose and why.

Naming convention reminder: every demo prompt should name the project (where the test gets stored) and the environment (where it runs). Omitting either triggers the narrowing contract — agent will ask, but it adds round trips. The env default credential auto-binds (release#152), so explicit credential_tag is optional unless you want a non-default tag.

Tool sequence (the canonical AI authoring flow — release#156):

ensure_crawl_for_authoring(url="https://store-qa.portnov.com/login")
  ⇒ {jobId, fresh, pages: [{url, title, elements: [...]}]}

# The LLM composes the YAML by reading the inventory, picking selectors
# that match the intent, inserting waits, choosing the right assertion.
# This is where the agent's reasoning matters — and what release#156
# pushed back into the agent's hands.

validate_ui_test_yaml(yaml_text=<composed-yaml>)
  ⇒ {valid: true, errors: []}    # iterate if needed

create_ui_test_from_yaml(name="...", yaml_text=<composed-yaml>,
                        project="User Management Platform",
                        tags="mcp-demo-flow-4,smoke,login")
  ⇒ {id: 142, projectId: 2, status: "ACTIVE"}

run_ui_test(test="...", environment="development",
            wait=true, summarize=true)
  ⇒ {status: "COMPLETED", summary: "All 6 steps passed in 7.2s"}

Key capabilities shown: the platform exposes building blocks (crawl, validate, persist, execute) — the LLM does the composition. This is the correct division of responsibility: rule-based composers can't reason about a page like an LLM can. The 2026-05-24 worked example built a 16-step e-commerce smoke test from natural language; see Authoring tests as an AI agent for the full walkthrough.

Flow 5 — Performance test (~60s)

Prompt:

Author a load test for the User Service API in development with a 500ms p95 budget and 1% max error rate, then run it and tell me how it went.

Tool sequence:

get_performance_test_types()
  ⇒ [{value: "SMOKE_TEST", ...}, {value: "LOAD_TEST", ...}, ...]
list_project_applications(project="User Management Platform")
  ⇒ User Service API id=2
resolve_swagger_url(application="User Service API", environment="development")
  ⇒ http://user-service:8089/v3/api-docs
create_performance_scenario(
  name="[MCP] Flow 4 — User Service load",
  project="User Management Platform",
  environment="development",
  base_url="http://user-service:8089",
  test_type="LOAD_TEST",
  p95_threshold_ms=500,
  max_error_rate=0.01,
  tags=["mcp-demo-flow-4"])
run_performance_scenario(
  scenario="[MCP] Flow 4 — User Service load",
  environment="development")
  ⇒ {jobId: "ab12-…", status: "PENDING", toolName: "ARTILLERY"}
get_execution_status(execution_id="ab12-…", kind="ui_job")
  ⇒ poll until COMPLETED
summarize_execution(execution_id="ab12-…", kind="ui_job")

Key capabilities shown: authoring + running an Artillery perf test without leaving MCP (release#124, 2026-05-23). Perf runs use the same agent-job table as UI tests, so get_execution_status / summarize_execution work unchanged with kind="ui_job".

Tag-driven follow-up

Once any of the demo flows have tagged scenarios/tests, the next run is a single tool call:

Re-run everything tagged mcp-demo-flow-1 in development

run_by_tag(tags=["mcp-demo-flow-1"], environment="development",
           project="User Management Platform", dry_run=true)
  ⇒ {dry_run: true, tags, environment, project,
     would_queue: {api_scenarios: [{id, name}, ...], ui_tests: [...]}}

# Confirm with user, then run for real:
run_by_tag(tags=["mcp-demo-flow-1"], environment="development",
           project="User Management Platform")
  ⇒ {dry_run: false, queued: [...], skipped: [...]}

One round trip. No list_* calls needed. See tag-driven workflows for more recipes.

Why this works

Application registry is the source of truth. Apps under a project know their applicationType, applicationTech, authRequirement, swaggerPath, gitUrl, and defaultBranch — enough metadata for Claude to pick a strategy per app without any human help. authRequirement and swaggerPath are new in release#107 + #126 (2026-05-23).
Names, not ids. Every tool that takes a project, environment, scenario, application, or UI test accepts a name. The progressive narrowing contract makes ambiguity a conversation, not an error.
Credentials never appear in the prompt. credentialTag references the environment's credential vault. No password leak risk in the conversation.
Errors are recoverable, not fatal. Mistyped tool args return structured {reason, ask_user, candidates} dicts; ID/kind mismatches return {error: "wrong_id_type", ask_user, received} so Claude self-corrects without re-running the test (release#142).
All operations are idempotent in the demo sense. Re-running any flow creates a new scenario and a new execution every time, with auto-tagged [MCP] names so cleanup is one query.

Compared to the curl demo

This same flow used to be scripts/mcp-demo.sh — 200 lines of bash + curl + python3 -c simulating what an MCP-wired Claude would do. With the MCP server shipped, it really is Claude doing the work, and the tool calls are visible in the Claude Desktop UI as it goes.

Tool surface at a glance

The full MCP server currently exposes 144 tools across 12 categories:

explore (8): list_projects, list_project_applications, resolve_swagger_url, list_environments, find_scenarios, find_ui_tests, find_ui_test_suites, list_pipelines
act (5): create_api_scenario, execute_scenario, run_ui_test, run_by_tag, run_pipeline
report (3): get_execution_status, summarize_execution, get_crawl_results
api authoring (4): parse_swagger, create_scenario_from_swagger, validate_scenario_yaml, create_scenario_from_yaml
ui authoring (7): crawl_ui, discover_form_fields, validate_ui_test_yaml, create_ui_test_from_yaml, run_ui_test_suite, recommend_engine, ensure_crawl_for_authoring (release#156 — building block; LLM composes the YAML)
performance (5, release#124): find_performance_scenarios, get_performance_test_types, create_performance_scenario, run_performance_scenario, get_performance_history

See tools-reference for the full signatures and return shapes.

The prompt​

What Claude does​

Demo flows for recording​

Flow 1 — API scenario from Swagger (~30s)​

Flow 2 — Build a UI test from YAML (~60s)​

Flow 3 — Suite across multiple engines (~90s)​

Flow 4 — Crawl + LLM-composed UI test (~60s) ★ release#156​

Flow 5 — Performance test (~60s)​

Tag-driven follow-up​

Why this works​

Compared to the curl demo​

Tool surface at a glance​

The prompt

What Claude does

Demo flows for recording

Flow 1 — API scenario from Swagger (~30s)

Flow 2 — Build a UI test from YAML (~60s)

Flow 3 — Suite across multiple engines (~90s)

Flow 4 — Crawl + LLM-composed UI test (~60s) ★ release#156

Flow 5 — Performance test (~60s)

Tag-driven follow-up

Why this works

Compared to the curl demo

Tool surface at a glance