VeriProof MCP server

Connect an AI agent to the VeriProof records and workflows its identity can access. Use the portal’s connection instructions for your deployment.

The VeriProof MCP server is generally available, including policy drafting and computer-use tools.

Supported protocol boundary

VeriProof uses C# MCP SDK 2.2.0 with Streamable HTTP. The server prefers stateless 2026-07-28 and supports the 2025-11-25 initialization flow for clients that use that revision. Check your client’s qualification record for the protocol revision tested with VeriProof.

Each request is self-contained. Clients do not need a persistent server session or a connection to the same server instance.

The MCP server does not expose customer support records or initialize customer-support integrations.

Each VeriProof deployment has one MCP endpoint. Register the exact address published by your deployment. In the customer portal, open More tools → Agent tools → Connect as an Administrator or Developer. Governance Engineers, Compliance Officers, and Business Owners use More tools → Agent tools. That page reads the deployment discovery document, so it works for VeriProof SaaS environments and customer-owned dedicated instances without a hostname convention.

For automated or headless setup, start with the portal URL and read /.well-known/veriproof-configuration. The returned services.mcp value is the canonical MCP address. The deployment’s /agent-setup/prompt.md contains client-specific setup commands.

After the client reaches that address, standard MCP authorization discovery takes over. VeriProof publishes OAuth Protected Resource Metadata and returns its location in an unauthorized challenge. The client discovers the authorization server, uses authorization code with PKCE, and requests a token for the exact MCP resource. See the MCP authorization specification .

The server uses your VeriProof user sign-in. The deployment-local VeriProof authorization service opens the identity provider configured for the customer portal. The agent never handles the user’s password.

After sign-in, the server applies the same tenant, application, role, and audit controls as the customer portal.

The client requests the deployment’s mcp.access delegated scope and an MCP-specific token audience. That scope permits a connection; the portal’s existing tenant, application, and role rules still decide which tools and records the user can access. MCP does not create a second permission system inside MCP.

The VeriProof authorization service supports authorization code with PKCE, protected-resource discovery, exact resource-bound MCP tokens, refresh-token rotation, and confidential dynamic registration. Registration accepts HTTPS callbacks and local loopback callbacks only. It returns one unique client secret, stores only its SHA-256 digest, and limits anonymous registration attempts. Registrations expire and can be revoked.

The authorization-server metadata advertises client_secret_post. Clients must send the secret to the token endpoint and must request the exact MCP resource. A trailing slash or a different resource is not treated as an alias. Tokens require the exact mcp.access scope.

The deployment publishes canonical tool metadata at /.well-known/veriproof-mcp-tools. Each record identifies read-only, destructive, idempotent, confirmation, caller-kind, capability, classification, and release status behavior. Setup and release checks must use this catalog as their source.

The MCP deployment also publishes /.well-known/veriproof-mcp-client-setup. It generates the deployed endpoint, a Copilot Studio Streamable HTTP schema, and a Microsoft 365 agent-connector template. Replace the displayed DCR reference with the configuration registered in Microsoft Developer Portal. The generated artifacts use runtime tool discovery and do not copy the tool list.

VeriProof supports Streamable HTTP at /mcp. It does not expose the retired SSE /sse and /message endpoints. Deployment monitoring can use /mcp/health for process liveness and /mcp/ready for the dependencies required by MCP tools.

The server continues a valid incoming W3C trace through the MCP transport and tool spans. It does not copy incoming baggage. Tokens, prompts, model output, evidence, and customer content must not be placed in trace baggage.

For Microsoft customers, use the Copilot Studio MCP onboarding wizard with Streamable HTTP and dynamic discovery. Microsoft 365 Copilot stores the issued client credentials in its Enterprise token store. Power Platform data policies can also govern access to the connector. See Connect an existing MCP server in Copilot Studio  and Configure Microsoft 365 Copilot dynamic client registration .

Supported workflows

• Understand your current access and applications.
• Search and page through sessions, then inspect the evidence behind a result.
• Reconcile overview, governance, compliance, alert, and inbox counts with source records.
• Review role-aware assigned work, review cases, and policy exceptions.
• Work with alerts and audit evidence.
• Govern computer-use actions when your deployment enables these tools.

Write tools require confirmation and an idempotency key. VeriProof records the action in the audit log. Read-only users cannot acquire write access through an agent.

MCP governs calls to the VeriProof tools listed below. It does not intercept or govern unrelated Copilot actions.

Role coverage

The MCP server can stand in for the portal when the work is data retrieval, investigation, reconciliation, or an approved decision. It returns the facts and permitted actions used by each role’s important pages. The portal remains the right place for visual configuration, large-form editing, accessibility checks, and work that depends on layout.

The portal and MCP server call the same application services. MCP does not recreate portal authorization or query tables through a generic database tool.

Tool catalog

Context and role-aware overview

• get_my_context confirms the deployment, user, role, scope, and accessible applications.
• get_application_access_scope explains whether access is tenant-wide or application-scoped, which policy sources establish it, and whether one supplied application ID is in scope. It does not reveal details about an inaccessible application. Auditors can pair it with list_audit_engagements; Developers and Business Owners can use it to diagnose assignment, group, ownership, explicit-scope, or custom-role access.
• get_dashboard_overview returns the source facts used by the role-aware portal overview.
• list_applications and get_application_overview return the caller’s authorized application inventory and application detail.

Sessions and evidence

• search_sessions supports a UTC day window, application, outcome, risk, rule-violation, review-status, archive scope, trace-ID, and opaque-cursor pagination filters. The default archive scope is Active; use All when drilling into an all-time dashboard total.
• get_session returns the authorized session detail behind a search result.
• get_session_evidence returns protected governance evidence for permitted audit roles.
• get_session_integrity_record returns VeriProof’s recorded proof state. It does not claim independent verification.
• get_audit_evidence returns an authorized audit engagement with its recorded compliance evidence snapshots. Use get_session_evidence for session-level evidence inside that engagement’s application and date scope.
• Auditors may pass an assigned auditEngagementId to narrow session, evidence, and integrity reads. VeriProof checks the signed-in auditor assignment, engagement status, tenant, application scope, and engagement dates; the argument can never broaden access.
• list_audit_engagements and get_audit_engagement show the engagement IDs and scope available to the signed-in role. Auditors see only their assigned active engagements.

Assigned work

• list_notifications returns the same role-aware notification records shown in the portal Inbox, including read state, linked application or workflow resource, due time, action state, and recorded outcome. Use state: "open" for notifications that have not been actioned and state: "completed" for actioned notifications. Compare both populations with list_my_work when checking whether session activity created the expected work.
• list_my_work uses the same role-aware source as the portal inbox. Responses retain stable work, source, session, and application IDs; source type; state timestamps; due dates; available actions; and the portal deep link. Compliance Officers receive their tenant-wide pending session-review and framework control-gap populations. Auditors receive their assigned active engagements so triage-my-work can discover the audit journey. Administrators receive the same open Developer evidence requests that produce overdue and stale action notifications, so those records can be reconciled without switching roles.
• get_review_case returns the current review summary and authorized decision history.
• get_human_review_case returns the canonical paused-workflow lifecycle, including protected action context, callback delivery and acknowledgment, decision, cancellation, expiry, and terminal state. It requires the owning application ID and applies the portal’s application access check before reading the case.
• get_policy_exception returns an authorized risk-acceptance request and its source state.

Governance, compliance, and alerts

• list_application_rules returns the application’s effective rules, including inherited tenant rules, enforcement modes, recent evaluation facts, and policy evaluation status.
• get_rule_evaluation returns one effective rule and its recorded performance. The rule must be part of the authorized application’s effective rule set.
• get_governance_summary, get_governance_trends, and get_slo_status.
• Business Owners can omit applicationId from governance summary and trend calls to use their complete assigned application portfolio. They still cannot open protected session traces or compliance scorecards.
• Auditor governance summary and trend calls use each assigned engagement’s application and date window. One engagement cannot widen another. Compliance framework results are also limited to the framework assigned to the engagement when one is specified.
• Governance outcome counts describe session-step results. Final session outcomes are a separate measure. The summary response labels both units and directs agents to search_sessions for the matching application and UTC window instead of treating the two counts as interchangeable.
• The governance workload score is bounded from 0 to 100. Use the separate pending-review count when you need backlog volume.
• get_compliance_summary and get_compliance_frameworks.
• list_alert_rules, list_alerts, and get_alert_summary.
• acknowledge_alert records a confirmed acknowledgement when the signed-in user’s effective permissions and application scope allow it. Supply an idempotency key and reuse it only for the same alert and note. The first durable acknowledgement remains authoritative on retry.

Policy drafting

These application-scoped tools use the same services as the native Policy workspace. They require delegated OAuth, application access, and canAuthorRegoPolicy:

• get_policy_authoring_context accepts an application ID and the discover context first, then returns a compact summary of both supported rule contexts. After the author selects one, it returns the exact input contract, readable field sources, active rules, control levels, and portal review link. Callers do not need to construct profile identifiers or raw data paths.
• compose_policy_rule_draft creates a reviewable draft from business intent and structured examples using contracted fields. Copilot supplies the intent; VeriProof compiles and tests it without calling another language model.
• validate_rule_draft validates and compiles the draft against the exact application contract.
• test_rule_draft runs deterministic policy cases without deploying the rule.
• assess_rule_impact assesses a saved session-rule draft against available historical sessions. It returns a clear no-data or not-supported state when replay evidence is unavailable.
• save_rule_draft requires explicit confirmation and an idempotency key. It returns the saved version, content hash, readiness, missing facts, linked work, and portal review link.

These drafting tools cannot activate, enforce, approve, delete, change tenant-wide rules, create Developer requests, or ingest evidence. Use the native Policy workspace for review and every deployment step.

Computer-use lifecycle

These five generally available tools connect computer-use actions to policy checks and evidence:

• get_computer_use_requirements returns the server-resolved requirements, permitted execution channels, connector requirements, and available assurance for one accessible application.
• begin_governed_session starts a governed computer-use session. VeriProof derives tenant, application, caller, and assurance authority from the authenticated connection.
• evaluate_computer_action checks one bounded semantic action before execution through the canonical policy runtime. The MCP result remains agent-reported.
• record_computer_action records the attributed outcome. A registered action-owning connector must claim its short-lived execution authorization exactly once.
• complete_governed_session records the reported terminal outcome and reconciles the session’s action sequence.

MCP alone does not observe the host, prove that the action ran, or enforce an action outside the client workflow. Host-observed or host-enforced assurance requires a registered connector at the execution boundary. See Govern computer-use agents for the integration boundary and supported assurance levels.

Deferred specialist analysis

Application health, DVR portfolio, cost, analytics, session intelligence, and experiment tools are not in the v1 catalog. Their source implementations remain disabled until their result contracts and role-aware application scope match the portal.

Confirmed decisions

• submit_review_decision records an approved, rejected, or follow-up-required review through the portal’s canonical review command.
• Only an authorized user-delegated connection may submit that decision. A registered workload or autonomous agent cannot approve its own review.
• The call requires the exact session ID, decision, explicit confirmed: true, and a caller-created idempotency key. Reuse that key only when retrying the same decision.
• The application service enforces the user’s permission and application scope and records the review’s durable audit projections. MCP never falls back to an administrator role.
• acknowledge_alert requires the alert ID, explicit confirmed: true, and an idempotency key. The shared alert service preserves the first actor, note, and time when a client retries.

Response contract

Every tool returns the same top-level JSON shape in both MCP text content and structuredContent:

The stable fields are ok, data, error, status, scope, filters, page, pageSize, total, nextCursor, and observedAtUtc.

{
  "ok": true,
  "data": {},
  "error": null,
  "status": "success",
  "scope": {},
  "filters": {},
  "page": null,
  "pageSize": null,
  "total": null,
  "nextCursor": null,
  "observedAtUtc": "2026-07-29T20:00:00.0000000+00:00"
}

data contains the tool-specific result. scope identifies any scope reported by the source service. filters records the tool arguments that produced the observation. Page-based tools return the next page number in nextCursor; notification pagination returns the required beforeUtc and beforeId values. When ok is false, error.code is stable for automation and error.message explains how to correct the request. Authorization failures never broaden scope or disclose protected records.

Drill-down and consistency checks

Summary output must identify its application scope and UTC window. Detail output retains stable source IDs and timestamps. This allows an agent or automated test to compare:

• overview totals with paginated session results;
• session rule violations and review state with open and closed inbox work;
• open, action-required notifications with the canonical assigned-work population;
• alert summaries with alert-trigger records;
• compliance and governance movements with the sessions and evidence in the same window.

Always exhaust pagination before reporting a mismatch. Report the exact filters, window, source IDs, and both observed counts. Do not silently broaden the signed-in user’s application or audit engagement scope.

For a repeatable role-by-role procedure, see Test VeriProof with MCP.

Included prompts

• investigate-session
• triage-my-work
• prepare-audit-evidence
• check-data-consistency

The session integrity record reports what VeriProof recorded. To check exported evidence without trusting VeriProof’s API, use the independent verifier.

See Security and permissions before enabling MCP in a shared agent.

Verify each supported client

Run the same checks against one server version through each client:

Test both supported protocol revisions and the tool catalog separately. A successful server build does not prove that a client can connect or use its permitted tools.