Test VeriProof with MCP

Run this guide against stable SDK 2.2.0. Test stateless 2026-07-28 and the supported 2025-11-25 initialization flow. Record the revision each client negotiates. Confirm that unknown revisions, incompatible capabilities, missing required metadata, and header or body mismatches are rejected. Do not use a preview package or custom negotiation layer.

Use MCP to check the data and authorization behind portal pages. Then inspect those pages in the browser. MCP cannot verify layout, accessibility, or visible interactions.

Start with the signed-in context

Call get_my_context first. Confirm:

• the expected deployment and customer;
• the signed-in role;
• the applications available to that user;
• the mcp.access scope.

Stop if any value is unexpected. Do not broaden the test by changing tenant or application IDs.

Run a role pass

Sign in as each supported role and run the check-data-consistency prompt. At minimum, cover:

• Administrator
• Developer with assigned application scope
• Governance engineer
• Compliance officer
• Business owner
• Auditor

Confirm that the returned applications, sessions, evidence, work, and actions match that role’s portal access. An unauthorized role must receive a clear refusal, not an empty success that hides an authorization problem.

On localhost, use list_local_test_identities and switch_local_test_identity to move between seed users without repeating sign-in. These tools are unavailable outside an approved local test host. Switch one identity at a time, wait for its calls to finish, and call get_my_context immediately after each switch.

Reconcile summary and drill-down data

Use one explicit UTC window and application scope for every related call.

1. Record get_dashboard_overview, get_governance_summary, get_compliance_summary, and get_compliance_frameworks.
2. Page through search_sessions until no cursor remains. Use archiveStatus: "All" for an all-time dashboard comparison; otherwise record whether the check used Active or Archived.
3. Retrieve open and closed list_my_work pages until hasNextPage is false.
4. Compare alert counts with list_alerts.
5. Inspect the smallest mismatched set with get_session, get_review_case, get_policy_exception, and get_session_evidence.

Pay particular attention to:

• session activity that should create or close an inbox item;
• rule violations and pending review state;
• framework score changes and the evidence that supports them;
• application totals and role-scoped application access;
• application totals that disagree with the underlying session records;
• open-versus-closed work transitions and their timestamps.

Report a mismatch

Include:

• deployment, role, and application scope;
• UTC start and exclusive end;
• tool names and exact filters;
• whether every result page was read;
• summary count and drill-down count;
• stable session, work-item, source, application, control, or alert IDs;
• source status and state-change timestamps.

Do not include tokens, application keys, prompts, model outputs, or unrestricted evidence content.

Test a write

Use a disposable case to test submit_review_decision. Confirm that the tester is authorized to make the decision before starting.

1. Read the case with get_review_case.
2. Ask the tester to confirm the exact session, decision, and comment.
3. Call submit_review_decision with confirmed: true and a unique idempotency key.
4. Repeat the same call with the same key and confirm no duplicate decision is created.
5. Read the case and related work again. Confirm the review and inbox transition agree.

Never set confirmed: true based on an assumption or a prior unrelated approval.

Repeat the nearest decision denial with a registered workload identity. It must not use submit_review_decision, inherit a human role, or approve its own paused work.

Test each supported client

Use the same server candidate for each row:

Record the server build identifier, client and framework versions, caller kind, and tenant and application scope. Keep the trace ID, result IDs, denial code, and cleanup result with that record. A successful connection alone does not complete the test.

Finish in the portal

Open the same role and records in the customer portal. Confirm the important page totals and drill-down records match the MCP results. Also check loading, empty, error, keyboard, accessibility, and side-panel behavior. These presentation checks are outside MCP.

Release gate

Treat the MCP pass as a release gate for shared data services, not as a demonstration. A release is not ready when a summary and its authorized drill-down disagree without a documented reason. Fix the shared application service so the portal and MCP receive the same result; do not add an MCP-only adjustment.