Skip to main content

Before you begin

Ask your administrator to enable the MCP Rigor framework and hosted runner. Select the correct organization and team. The MCP target and bearer token must authorize only the resources and actions needed by the test.

Generate natural-language tests

  1. Open Test Automation and select MCP Rigor as the framework.
  2. Select the source requirement and include its approved MCP tool, resource or prompt contract, input arguments and expected behavior.
  3. Generate the review-only package. Browser page objects and journeys are not required.
  4. Review the generated .mcpr natural-language suite and its assertions.
  5. Approve the package before execution. Existing YAML suites remain supported.
Example discovery smoke test:
Discovery confirms the server can list tools; it does not demonstrate business requirement coverage. If a sufficient contract is missing, generated fallback tests remain discovery-only and leave acceptance coverage unverified.

Execute and review evidence

  1. Configure protected parameters MCP_URL and MCP_TOKEN; do not paste tokens into requirements, source code or reports.
  2. Use a public HTTPS Streamable HTTP endpoint on port 443. Ensure the short-lived OAuth or bot token remains valid for the run.
  3. Review the hosted-worker budget and credit consent where metering is enabled.
  4. Execute the approved suite through the configured LoopIQ runner.
  5. Review execution counts and sanitized JSON evidence. Link the run to the relevant release using the existing evidence workflow.
A successful run does not automatically approve a release certification. Hosted execution does not support arbitrary stdio servers, token shell commands, interactive OAuth, custom extensions, snapshots, remote datasets or LoopIQ Tunnel. Private networks and cloud metadata endpoints remain blocked. These are hosted LoopIQ restrictions, not a statement that MCP Rigor itself lacks those capabilities.