Tool reference

All 26 Certivant MCP tools grouped by the job they do — queue triage, sending and tracking forms, lifecycle actions, decision explanation and network risk, live ID verification sessions, KYB registry checks, and reporting — with what each returns and what it deliberately does not.

The catalogue is 26 tools by default, deliberately capped at about that count. Past it, model tool-selection accuracy degrades measurably, so a new capability replaces or consolidates rather than appends — list_expiring_documents takes a mode argument instead of shipping two sibling tools, and the live ID verification tools fold list + detail into one tool and reschedule / cancel / re-invite into another. Three more compliance tools exist behind operator flags (see the end of this page).

Each tool is annotated honestly (readOnlyHint, destructiveHint, idempotentHint) so your host can gate the ones with real-world consequences. Five tools send actual email (or SMS). Two are destructive. Everything else reads.

send_form_to_customer, send_verification_reminder, and renew_verification email real customers. None of them are idempotent: calling one twice sends two emails. If a call errors, check list_form_deliveries before retrying rather than re-sending blindly.

Get through the day

Tool	Returns	Does not return
`get_todays_queue`	One aggregate snapshot for the whole organization: counts per status, escalated and awaiting-second-review, stalled (no activity for N days, default 7), failed sanctions checks, escalations past the review SLA, re-KYC due, plus 24h/7d activity.	Counts only — no request IDs, no names, no applicant data. Follow up with the list tools to act on a bucket.
`find_verification`	Free-text lookup by person name, email, company name, or external reference. A compact disambiguation list — id, status, type, decision, score, timestamps, days-since-update — plus how many matched, so an ambiguous search stays visibly ambiguous.	Email addresses are not returned by default. Applicant names arrive inside the untrusted envelope.
`list_stalled_verifications`	Non-terminal cases with no activity for N days (default 7), each with `daysWaiting` and the `pendingDocTypes` still owed. The "who do I chase?" list — these wait on the applicant.	Reviewer-side backlog. Escalations and SLA breaches live in `get_todays_queue`. Pairing the filter with a terminal status returns nothing.
`whats_changed_since`	Shift handover: everything touched since a timestamp, oldest first, grouped by the status they now hold, with how long ago each moved.	Natural language times. `since` must be a full ISO-8601 date-time such as `2026-07-18T00:00:00.000Z` — a bare date is rejected.
`get_verification_status`	A slim status shape for one request ID — status, timestamps, decision, overall score. Cheap enough to poll.	No personal data at any setting.

Start with get_todays_queue, then drill in. Do not reconstruct the queue by looping find_verification — the per-tenant rate limit is 120 requests per minute and a loop exhausts it before it finishes.

Move work forward

Tool	Returns	Notes
`start_verification`	Creates one verification and returns the link the applicant uses, in a single call.	Sends no email — the link comes back to you to deliver. Not idempotent.
`start_verifications_batch`	Up to 50 rows in one call. Each row is validated and created independently; one bad email fails that row only and successful rows are not rolled back. Failures report the `index` into your list and the reason.	Use instead of looping `start_verification`. Report failures individually — never as "some failed".
`send_form_to_customer`	Sends a real email. Creates the applicant, creates the request, mints the personal link, sends the invitation, and returns a tracking handle for `get_delivery_status`.	Not idempotent — twice means two applicants, two requests, two emails. Get the form id from `list_verification_forms` first; guessing 404s.
`send_verification_reminder`	Sends a real email. Nudges an applicant with a fresh link that resumes the same request — status and already-uploaded documents are preserved.	Only while the case is `PENDING_UPLOAD` or `DOCUMENTS_READY`. Throttled server-side — see Safety & limits.
`renew_verification`	Sends a real email. Creates a new request for the same applicant, linked to the original, requiring the same documents, and emails a re-verification notice.	The original is untouched. Not idempotent — each call is another renewal and another email. Find the due cases with `list_expiring_documents` in `renewals` mode first.
`resubmit_verification`	Resets a REJECTED request back to `PENDING_UPLOAD` so the applicant can retry — the usual fix for a blurred photo or expired ID.	Destructive. It deletes the existing checks and risk score, so `explain_verification_decision` can no longer explain the rejection afterwards. Read the explanation first. Sends no email.
`list_verification_forms`	The catalogue you send from: id, name, type (`kyc` = individual, `kyb` = business), status, public slug. Published forms only by default.	No applicant data of any kind. An unpublished form sends the recipient to the generic upload flow instead of the form you meant.
`list_form_deliveries`	Everyone a given form was sent to and where each stands — `sent`, `started`, `completed`, `bounced`, `failed`. `status: sent` is the chase list.	Recipient emails are masked by default.
`get_delivery_status`	One delivery's full lifecycle: sent, delivered, opened, started, completed, how many reminders went out and when the last one did.	Trust `startedAt`/`completedAt` — observed server-side. `openedAt` depends on mail-client open tracking, which most clients block; a null `openedAt` is not evidence the person ignored the email.

Understand a decision

Tool	Returns	Does not return
`explain_verification_decision`	The scorer's actual reasoning for one request: which tier-1 disqualifiers or tier-2 review triggers fired, which scoring factors failed and on what evidence, which could not be evaluated and why, the score against the threshold applied, any policy rules that fired, network-risk red flags with how each was detected, and a written case-note summary. It also flags when a human reviewer overrode the automated verdict.	See the gap below — structured reasoning is not present on every request.
`get_verification_result`	The outcome: status, decision, trust score, every check that ran and whether it passed, a pass/fail/not-applicable count over the scoring factors, which disqualifiers or review triggers fired, `redFlags` and a `network` summary (VPN / proxy / Tor / data-centre / relay detected, how, the IP's country and network operator, whether the device time zone matches), what documents were supplied, and what the applicant still owes.	No personal data by default — no name, DOB, document numbers, addresses, or OCR text. `include_pii: true` widens the response to identity fields and is recorded.

reasoningAvailable: false is common. Structured scorer reasoning (verdictMeta) is only recorded on verifications scored since it was introduced, so many — in practice most older — requests come back with reasoningAvailable: false and no factor breakdown. In a spot check of one live tenant, none of the 12 oldest requests had it and only 5 of the 12 newest did. When you see it, describe what the status and checks show and say the reasoning was not recorded. Do not infer why the scorer decided.

Network risk

Every verification's connection is checked by Certivant's own detection — no third-party vendor — for Tor, VPN, proxy, hosting / data-centre and privacy-relay networks. Both tools above report it as redFlags plus a network object:

detected — the kinds found; detections — each with its source (a daily-refreshed IP list, the operator name, a WebRTC or DNS leak, an IP shared by many applicants, or a browser round trip far longer than the edge measured).
ipCountry, networkOperator, deviceTimezoneMatchesIp, ipToGpsDistanceKm, likelyRealNetworkCountry.
Never the IP address, host name or city — those are personal data.
assessed: false means not checked (no applicant IP, e.g. API-created requests) — never "clean".

A red flag describes the connection, not the person: privacy-minded and corporate users use VPNs. Each organization chooses per kind whether a detection rejects, escalates, only flags, or is ignored.

Live ID verification

Tool	Returns	Notes
`list_live_verifications`	Without `conference_id`: sessions filtered by status (`scheduled`, `in_progress`, `completed`, `cancelled`, or `expired` = never took place), request, reference or date range. With `conference_id`: that session's detail — host, whether the applicant joined and consented, session settings (applicant file upload, automatic verification of received documents), decision and outcome, recording and certificate.	No applicant name or email unless `include_pii: true` with a `conference_id` (audited).
`schedule_live_verification`	Schedules a session for an existing request (`scheduled_for` with a timezone, or `start_now`), with optional `applicant_file_upload` and `auto_verify_documents`.	Emails / texts the applicant. Not idempotent; a request with a joinable session returns 409. The one-time join link is returned in prose only — share it with the applicant alone.
`manage_live_verification`	`action`: `reschedule` (participants notified), `resend_invitation` (fresh link, old one stops working), or `cancel`.	Annotated destructive: cancel is irreversible. Confirm before cancelling or re-inviting.

KYB

Tool	Returns	Notes
`get_business_record`	What the company declared on a BUSINESS request: company name, registration number, country and type of incorporation, KYB status, the authorised representative and how they were matched, plus declared directors and beneficial owners with ownership percentages and any linked KYC request verifying a UBO.	A pure read of what Certivant holds. Makes no registry call and costs nothing. It does not tell you whether any of it is true.
`check_company_registry`	The diff between the public corporate registry and what the company declared: which declared directors the registry does not list, and which registry directors were never declared. The diff is the answer; the raw record is supporting evidence.	Not a read — it makes a billable external registry call and, on a match, marks the KYB record `verified`. Call once per company, never in a loop.
`submit_business_details`	Records a company's KYB details against an existing BUSINESS request — legal name, registration number, country and type of incorporation, directors, beneficial owners.	Side effects beyond the record: it triggers a background registry lookup and creates a separate INDIVIDUAL verification request for every beneficial owner at 25%+ ownership (the FATF threshold). Never call it speculatively or to "fix a typo".

Known limitation: check_company_registry is currently failing live. The upstream registry call returns 401 because the OpenCorporates API key is not being passed through, so the director-match diff is unproven against a real registry match. Until that is fixed, expect an error rather than a diff, and do not build a workflow that depends on this tool's happy path. get_business_record and submit_business_details are unaffected.

Reporting & documents

Tool	Returns	Does not return
`get_compliance_metrics`	The tenant-wide rollup: approval rate and the full funnel (submitted / pending / processing / approved / rejected / escalated), volume by document type, outcomes by nationality, a 30-day daily trend, and per-check failure rates showing which check fails most — OCR, face match, liveness, sanctions.	Not a list of rejection reasons. "Top rejection reasons" is not something this tool produces; what it gives you is check-failure rates. Also no row data and no personal data at all.
`list_expiring_documents`	Two modes. `documents` (default) — verifications whose uploaded documents expire or go stale within N days (an ID past expiry, or a dated supporting document older than the tenant's recency window). `renewals` — verifications whose own periodic re-check is due (the request's `expiresAt`), overdue or falling due within N days.	These are different questions. A valid passport on a request due for its annual refresh appears only under `renewals`. Run the mode you were actually asked about.
`list_verification_documents`	Metadata only for every document on one request: type (`passport`, `id_card`, `drivers_license`, `selfie`, `business_reg`, `utility_bill`, `bank_statement`), side, processing status, file type and size, upload time, and the document's own extracted dates including whether it reads as expired.	No image, no OCR text, no document number, no name, no address, no MRZ — the OCR blob is structurally excluded and cannot be obtained at any setting.
`get_document_download_url`	A short-lived (15-minute) signed URL so a human can view one uploaded document, plus its lifetime.	It does not return the file, and the agent must not fetch it — an identity document pulled into a conversation is a passport scan copied into a model provider's logs. The link needs no credentials, so treat it as a secret: hand it to the person who asked and stop.

Gated compliance tools

Three tools exist but are off by default. The gate is applied at registration, so with the flag unset the tool does not appear in tools/list at all. Each needs its own flag set to exactly "true" on the MCP server and an API key with the kyc:manage scope:

Tool	Flag	What it does
`decide_verification`	`CERTIVANT_MCP_ALLOW_DECISIONS`	Records a manual approve / reject. A regulated decision taken in a context that holds applicant-controlled text — enable deliberately.
`export_applicant_data`	`CERTIVANT_MCP_ALLOW_EXPORT`	Starts a GDPR data export job.
`erase_applicant`	`CERTIVANT_MCP_ALLOW_ERASURE`	GDPR erasure — irreversible; requires echoing a confirmation.

What is not in the catalogue

get_fraud_signals, explain_to_applicant, submit_verification — not shipped.
Settings (thresholds, network-risk actions, privacy policy, roles) — managed in the dashboard only; the connector's API key cannot read them.

Tool reference

On this page