Verifa's MCP server lets Claude, Cursor, and any other agent that speaks the open Model Context Protocol work directly in your account — list sessions, review cases, manage screening, even handle compliance redactions — through structured tools, not LLM-generated cURL.
45 structured tools across eight toolsets — every action your reviewers take from the dashboard, plus the read paths your data engineers usually script against the REST API. Tools are grouped so you can hand an agent exactly the surface it needs and nothing more, set with one URL flag at connect time.
Identify the calling key, list API keys, fetch usage stats.
List, fetch, follow event timelines, create new sessions, reprocess terminal ones.
Search verified identities, fetch one by id or external ref, manage tags.
Review queue read + claim, assign, comment, approve, reject, escalate.
List Smart QA findings, acknowledge or dismiss with audit-recorded reason.
Screening checks (AML, IP / phone / email risk) — list, drill into hits, rerun.
List workflow definitions, fetch one, trigger a re-run against a session.
Screening lists, list items, the auto-deny blocklist — list, add, remove.
Permanent deletions for GDPR right-to-erasure: redact session, redact identity, bulk redact, delete blocklist entry, revoke session link. Hidden from agents unless the connection URL explicitly names this toolset — and even then, gated by four independent safeguards.
The MCP server speaks the open Streamable HTTP transport at https://api.withverifa.com/mcp and authenticates via your existing API keys. Connect Claude Code in one line:
# Connect Claude Code to your Verifa account claude mcp add --transport http verifa \ "https://api.withverifa.com/mcp?toolsets=cases,findings&read_only=true" \ --header "Authorization: Bearer vk_live_your_key"
Snippets for Cursor, Claude Desktop, and the Anthropic API connector are in the docs and on the in-app AI Integrations page.
Agents get powerful, but they also get scoped, throttled, and audited. The five destructive tools sit behind four independent safeguards — every one of which must pass before a single redaction or blocklist delete can fire.
The agent uses your normal API keys — same prefix, same hash verification, same expiry / IP allowlist / subscription gate. Per-tool scope checks reuse the existing vocabulary; destructive operations require a separate destructive:write scope that's never on by default and never available on publishable keys.
The destructive toolset is hidden from tools/list unless the connection URL explicitly names it (?toolsets=…,destructive). Read-only mode (?read_only=true) hides every write tool in one flag, regardless of the API key's grants.
Every MCP request burns one slot in a 120-requests / minute bucket separate from your REST quota. Destructive operations get a second, tighter cap: 5 per hour per key. A runaway agent can't burn either your billing or your compliance posture.
Every tool invocation writes an mcp.<resource>.<verb> row to your audit log with the actor key, the input arguments (PII-scrubbed), and the outcome. Destructive tools additionally require a 10-character reason recorded in the same row. Filter to "MCP only" in the dashboard or via ?action_prefix=mcp on the events API.
REST gates sensitive-data access with cookie-bound user tokens and a per-route access-window check. MCP has only API-key auth — no per-end-user consent attestation flows through it — so the agent-facing surface starts from a more conservative posture: identifiers and metadata yes, PII no.
get_session returns the session id, status, country, requested checks, timestamps, and counts. It does not return the metadata JSONB field — orgs commonly place applicant emails and internal refs containing PII there. That data is reachable via REST, deliberately not via MCP.list_identities / get_identity / search_identities return ids, statuses, document types, country, tags, and session counts. They do not return name, date of birth, document number, SSN, email, phone, or address.rerun_check decrypts PII internally to re-issue the provider lookup but never returns the decrypted PII to the agent. It also enforces the org's sensitive-data access window — re-runs against sessions past their retention horizon are rejected, the same way the REST equivalent rejects.If a future MCP tool needs to return PII to the agent, the rules are written down: a dedicated pii:read scope (not reused from any existing *:read), a mandatory call to the access-window helper, a tighter rate-limit bucket than the default 120/min, and field-by-field disclosure in the integration guide.
Two related caveats:
external_ref is customer-controlled. Many orgs put emails or other identifiers there despite our guidance. Treat it as untrusted string data, not a typed identifier.external_ref or screening-hit reason can carry instructions an attacker planted. Especially relevant for the destructive toolset: only enable it when you control the agent's prompt boundary.Create a free Verifa account, mint a sandbox API key, and have Claude Code triaging your review queue before the kettle boils.