Skip to content

Safe actions across chat, MCP, and Windows integration

Web chat and MCP use the same capability catalogue and versioned domain services. Reading and writing therefore follow the same project, role, object, and version checks. Supported domains include the test library, requirements, planning, execution, results, reviews, relations, defects, attachments, release and change knowledge, administration, and Word import or export.

An AI answer or MCP preview does not change project data. Writes are prepared, reviewed, explicitly confirmed, and audited.

Prepare, review, commit, and audit

  1. Prepare: Chat or MCP turns the requested domain operation into a concrete, permission-checked preparation.
  2. Preview: Review the target, proposed change, effects, warnings, and—where relevant—the expected object version.
  3. Commit: Confirm only an unchanged preview that you understand. Restart after an expiry or version conflict.
  4. Audit: Review the result, deep link, and audit record. Idempotency prevents a technical retry from silently applying the same change twice.

Missing permission, stale version, unknown capability, or invalid arguments fail closed rather than applying a partial update.

Configure MCP with least privilege

MCP uses JSON-RPC 2.0 at POST /mcp. Personal project API keys operate with the roles and permissions of their active project user. Global administrative keys are separate; a global key needs an explicit additional approval before it can access project tools.

  • Create keys in the intended MCP API-key administration and copy the secret immediately; it cannot be displayed again.
  • Use a short lifetime, minimal scopes, and a clear purpose.
  • Pass the project unique ID or an approved project path instead of relying on an implicit global context.
  • Inspect the tool catalogue and capability explorer before automating an operation.
  • Revoke keys that are no longer required or may have been exposed.

Reusable test steps through MCP

For reusable test steps, ztm_project_reusable_test_steps uses the project.reusable-test-step.read capability:

operation Other arguments Result
list optional includeArchived Permitted blocks with their current fixed revision and fingerprint
detail blockID Content, revision history and permitted usages
composition testCaseVariantID Current library-variant sections and fingerprint

Writes use ztm_project_action_prepare and ztm_project_action_commit. The API key must allow the exact write capability; general write access is insufficient. Supply these arguments:

Capability Arguments
project.reusable-test-step.save block with ID (empty when creating), TestUnitID, Title, StepsRaw, ExpectedRaw, Note, Archived; plus expectedFingerprint (empty when creating)
project.reusable-test-step.composition.save testCaseVariantID, the complete ordered sections, and expectedFingerprint
project.reusable-test-step.composition.detach testCaseVariantID and expectedFingerprint

A reusable section contains BlockID and the explicitly selected Revision. A local section has no BlockID and contains StepsRaw plus optional ExpectedRaw. Raw text follows the project's HTML or Markdown mode. Preserve every unchanged local section when saving a composition. An intentionally empty expected result remains empty.

save creates a new fixed revision; Archived: true archives the block. There is no physical-delete command or automatic update of all usages. Convert one section to local content by replacing its reference with its resolved raw texts. The detach command converts the entire saved composition.

Review old and new content before committing, reuse the same idempotencyKey for technical retries, and commit only the returned previewToken. Re-read and prepare again after a fingerprint conflict. The shared Runtime service checks source-read and target-write access and rejects Quick tests. Existing synchronization returns skippedManagedContent for preserved historical content: managed steps/results in existing runs stay frozen while other selected fields may synchronize.

Local Bridge and controlled local actions

Zeta Test Local Bridge connects supported web workflows to controlled local Windows functions. The web server cannot start arbitrary local processes. Chrome or Edge communicates through the browser extension with an installed Native Messaging host, while a machine-level policy permits only named, typed actions.

  1. An administrator deploys the Native Host and browser extension, then connects only the intended ZTM website.
  2. Customer IT defines approved process actions in the Local Bridge policy. Free command lines and legacy Lua remain blocked in the web client.
  3. External tools use a structured reference such as ztm-local-bridge:action-id. Only an installed and policy-approved action can run.
  4. Use administration to verify status, version, checksum, endpoints, and the generated Chrome or Edge policy values.

Treat the extension, Native Host, site association, and local policy as one security boundary. A connected bridge does not replace project or object permissions.

Test case versions

ztm_project_test_case_versions reads test case versions through project.test-case-version.read. List, content, comparison, historical files and preview enforce the same object permissions as the Web client. Restoration uses the prepared and explicitly confirmed project.test-case-version.restore write capability; arguments and workflow are also described in the REST chapter.