MCP Integration

This guide explains how to configure MCP (Model Context Protocol) integration so AI-powered agents - such as those in n8n, Cursor and other MCP-compatible tools - can create identity verification challenges and check their status without requiring custom integrations in your ITSM or SOAR systems.

MCP server URL: https://challenge.veraproof.io/mcp
Use this URL when adding the Challenge MCP server in your MCP client. All MCP requests (create challenge, get challenge status) are sent to this endpoint with a Bearer token from the OAuth 2.1 flow.

Why MCP Integration?

The MCP integration lets AI agents work with Challenge using a standard, secure protocol:

No bespoke integrations required – AI agents can create and check challenges through the MCP server instead of building and maintaining separate webhook or API integrations inside each ITSM or SOAR tool.
OAuth 2.1 + PKCE – Clients authenticate with short-lived tokens and optional client secrets; no long-lived API keys to rotate in agent configs.
Scoped access – You control which clients can create challenges (challenges:create) and which can only read status (challenges:read).
Centralized revocation – Deleting an MCP client in the admin console immediately invalidates all of its tokens.

You can support both human-driven workflows (e.g., analysts in Cursor, Claude, Goose, etc) and automated ones (e.g., Tines, Torq, n8n, SOAR playbooks, etc) through the same Challenge tenant.

Overview: Two Ways to Configure MCP Clients

Challenge supports two ways to register MCP clients:

Approach	Best for	How it works
Dynamic Client Registration (DCR)	Quick setup; tools like Cursor that support “connect with OAuth”	The client starts authorization with `client_id=dynamic`. An admin or owner approves once; Challenge creates a new OAuth 2.1 client and completes the flow. No pre-registration.
Static (pre-registered) client credentials	Automation, scripts, or tools that need a fixed `client_id` and `client_secret`	You create an “MCP Integration” in the admin console and get `client_id` and `client_secret` once. The client uses these with the token endpoint (and PKCE if supported).

Both approaches use the same OAuth 2.1 authorization server, token endpoint, and MCP API; only how the client is created differs.

Option 1: Dynamic Client Registration (DCR)

Use DCR when your MCP client can start an OAuth flow without pre-configured credentials. The client will use client_id=dynamic (or no client_id) and a redirect URI (e.g. https://localhost:5000/oauth/callback). Only tenant admins or owners can complete this flow as they are authorizing a new MCP client for the tenant.

Steps (admin or owner)

Log in to the Challenge admin console at challenge.veraproof.io.
In your MCP-capable tool (e.g., Cursor), add the Challenge MCP server. For Cursor, add a DCR MCP server entry in your MCP settings (e.g. in Cursor Settings → MCP or your MCP config file) with the Challenge MCP URL:
```
{
  "mcpServers": {
    "veraproof_challenge_dcr": {
      "url": "https://challenge.veraproof.io/mcp"
    }
  }
}
```
Then start the flow to connect (e.g. add or open the server). When prompted for authorization, you will be sent to Challenge’s OAuth authorize URL.
On the Challenge consent screen, review the requested scopes (e.g. challenges:create, challenges:read) and click Allow.
You are redirected back to the client. Challenge has created a new OAuth 2.1 client for your tenant and completed the authorization. The client can now obtain access tokens and call the MCP tools.

The new client appears under Integrations → MCP Integrations as a “dynamically registered” client with the clients name in brackets. You can delete it at any time (see Deleting MCP clients).

Requirements for DCR

You must be logged in as a tenant admin or owner before trying to connect the MCP client.
The client must send a valid redirect_uri (e.g. https://... or cursor://anysphere.cursor-mcp/oauth/callback).
The client must send a PKCE code_challenge (and code_challenge_method, e.g. S256).

Option 2: Static (Pre-Registered) Client Credentials

Use this when you need a fixed client_id and client_secret for scripts, automation, or MCP clients that cannot use the interactive DCR flow.

1. Create an MCP Integration

Log in to the Challenge admin console at challenge.veraproof.io.
Go to Integrations → MCP Integrations (OAuth 2.1 + PKCE).
Click Add MCP Integration.
Fill in:
- Display Name: A friendly name (e.g. “SOAR MCP Client” or “Automation”).
- Redirect URIs: One per line. Allowed: https://..., http://localhost... (or http://127.0.0.1), and for Cursor: cursor://anysphere.cursor-mcp/oauth/callback.
Click Create (or equivalent).
Copy the Client ID and Client Secret – the secret is shown only once. Store them securely.

2. Use the Credentials

Your client uses the standard OAuth 2.1 flow:

Authorize: Send the user (or service account) to the authorization URL with your client_id, redirect_uri, scope (e.g. challenges:create challenges:read), PKCE code_challenge/code_challenge_method, and response_type=code.
Token: After the user approves, exchange the code at the token endpoint using client_id and client_secret (e.g. client_secret_post) and the PKCE code_verifier.
MCP: Use the returned access_token as a Bearer token when calling the MCP server (create challenge, get challenge status).

Discovery and metadata:

MCP server URL: https://challenge.veraproof.io/mcp
Authorization endpoint: https://challenge.veraproof.io/oauth/authorize
Token endpoint: https://challenge.veraproof.io/oauth/token

If you lose the client secret, use Regenerate client secret for that MCP integration in the admin console. The new secret is shown once; all existing tokens for that client remain valid until they expire or the client is deleted.

Deleting MCP Clients

You can remove MCP clients from the admin console in two ways, depending on how they were created.

Pre-registered (static) MCP integrations

Go to Integrations → MCP Integrations.
Find the integration and click Delete.
Confirm.

Effect: The OAuth 2.1 client linked to that integration is deleted. All tokens and authorization codes for that client are revoked. Any further request that uses a token issued to that client will receive 401 Unauthorized.

DCR-created (dynamic) clients

Go to Integrations → MCP Integrations.
In the list of dynamically registered clients, click Delete next to the client you want to remove.
Confirm.

Effect: Same as above: the client record is deleted, all of its tokens and authorization codes are removed, and any existing access tokens for that client immediately become invalid (401 with reason such as “Invalid or expired token”).

Why this matters

Deleting an MCP client is the way to revoke access for that client (e.g. a lost device, decommissioned tool, or former vendor). There is no separate “revoke” step; deletion revokes all access for that client immediately.

Scopes and Capabilities

MCP clients can be granted the following scopes (typically at authorization time):

challenges:create – Create identity verification challenges (standard or Slack-based) via MCP tools.
challenges:read – Read challenge status via MCP tools.

These align with the same capabilities as the webhook API (create challenge, get challenge status), so AI agents can drive the same workflows without ITSM or SOAR-specific integrations.

Best Practices

Use DCR for interactive tools when possible for quick and easy set up; use static credentials for scripts or tools that don’t support DCR.
Store client secrets securely – Never commit them to version control or share them in plain text.
Limit scopes – Grant only the scopes each client needs.
Remove unused clients – Delete MCP integrations or clients when they are no longer used so tokens cannot be reused.
Regenerate secrets if compromised – Use “Regenerate client secret” for the affected MCP integration and update your automation.

Support

For issues or questions about MCP or OAuth 2.1 configuration, contact [email protected] or refer to the main documentation.