AI Agents & MCP
Most integrations now get written with an AI assistant in the loop. YeboVerify ships an MCP server so your agent can do the integration properly — it gets the walkthrough, the API quirks, and the ability to create your account and run real verifications, without you hand-copying anything from these docs.
Install
claude mcp add yeboverify -- npx -y github:omegathesecond/yeboverify-mcpNo API key needed to start. Then ask your assistant:
"Set up YeboVerify identity verification in this project."
It calls start_here, receives the full integration briefing, and walks you through creating an account and wiring the code.
For Cursor, Windsurf, or any other MCP client, the stdio config is:
{
"mcpServers": {
"yeboverify": {
"command": "npx",
"args": ["-y", "github:omegathesecond/yeboverify-mcp"],
"env": { "YEBOVERIFY_API_KEY": "yv_test_…" }
}
}
}Leave out the env block entirely until you have a key. The server starts without one, and the two onboarding tools work regardless — so your agent can get you a key from inside the editor rather than sending you off to a signup page.
The repository is private
npx -y github:… needs your GitHub account to have access to omegathesecond/yeboverify-mcp, and the package is not on npm yet, so the command fails to authenticate until we grant you access. Ask us and we'll add your GitHub username. Everything on this page works the moment you have it.
Point the server at dev with YEBOVERIFY_BASE_URL=https://dev-api.yeboverify.com.
Tools
Onboarding — no API key required:
| Tool | What it does |
|---|---|
start_here | The integration briefing: getting keys, sandbox-first testing, which integration path to pick, webhook handling, and the three quirks that most often produce broken integrations. |
create_sandbox_account | Creates a real account from a business name + work email and returns both keys, so you can start without leaving the editor. |
Runtime — need a key:
| Tool | What it does |
|---|---|
create_verification_session | Starts a hosted KYC flow; returns a verifyUrl to send the user to. |
get_verification | One verification by id — status, decision, scores, extracted ID fields. |
list_verifications | Recent verifications, optionally filtered by status. |
create_company_verification | Starts a KYB check (documents + registry + directors). |
get_account | Account name, plan, webhook URL — the cheapest proof a key works. |
Failures come back as MCP error results carrying the real API message. Nothing is swallowed or replaced with placeholder data, so your agent sees what actually went wrong instead of inventing a reason.
create_sandbox_account creates a real account and asks for a real name and email — the email is the only way to recover a lost key. A good agent will confirm both with you first rather than inventing them.
Without MCP
If you'd rather your assistant just read the docs, point it at https://docs.yeboverify.com/llms.txt — a curated, machine-readable index of this documentation. llms-full.txt is the entire documentation set as a single file, for pasting into a context window.
What agents get wrong
An LLM writing a YeboVerify integration will pattern-match a conventional REST API and get these three things wrong. start_here and llms.txt both state them; if you're prompting by hand, paste them in.
1. /v1/sessions/* responds flat. Every other endpoint wraps its payload in data. The session routes put fields next to success:
// ❌ undefined
const { verifyUrl } = (await res.json()).data;
// ✅
const { verifyUrl } = await res.json();This is not hypothetical — it is exactly what broke our own Node SDK, which returned undefined from createSession() and so never produced a link for anyone.
2. verifyUrl uses a fragment, not a query parameter.
✅ https://verify.yeboverify.com#session=TOKEN
❌ https://verify.yeboverify.com?session=TOKENThe # keeps the token out of server logs, analytics, and the Referer header. Don't rewrite it, and don't log the whole URL — it is a live credential.
3. YeboVerify sends your end user nothing. No SMS, no email, no OTP, no verification code — there is no endpoint that does it. You deliver verifyUrl. Its only outbound message is the webhook to your server. If a user says "I never got a code", what failed is your own delivery of verifyUrl.
Also available: the CLI
For a non-agent setup, the CLI wires a project up in one command:
npx -y github:omegathesecond/yeboverify-cli initIt validates your key, writes it to .env, optionally registers your webhook, and scaffolds a working hosted-flow example. Same private-repo caveat as above.