An MCP (Model Context Protocol) server that lets a coding agent (Claude Code, Cursor, or your own automated system) initiate and read back Nexiel Verify and Nexiel Age checks, and validate/generate Nexiel Invoice/ViDA e-invoices, without you writing any HTTP client code.
agent-toolkit.nexiel.io is live. Everything below (the tool list, request/response shapes, and auth model) describes the real, hosted server. Point an MCP-capable client at it directly using Step 2 below.
Scope: two different trust models in one server. The Verify/Age tools are a thin adapter: every call is forwarded, as-is, to @nexiel/verify-api's real REST endpoints, authenticated with your own API key. The Invoice/ViDA tools are different: they call @nexiel/einvoice's real EN 16931 validator/serializers and @nexiel/peppol-transport's real (SANDBOX-ONLY) transport layer directly, take no bearer token at all, and cannot issue, persist, or look up the status of a real invoice (see "Nexiel Invoice / ViDA tools" below for exactly why). This toolkit still never touches Nexiel Screen or Nexiel MiCA, and never exposes a way to resolve or clear a POSSIBLE_MATCH result. That gate does not exist anywhere in this toolkit, on purpose: the EU AI Act human-in-the-loop requirement always applies, with no automation shortcut.
The Agent Toolkit MCP server holds no credentials of its own. It does not store an API key, does not have elevated access, and does not decide what a caller is allowed to do. Every single tool call carries forward the Authorization: Bearer token you supplied when you pointed your MCP client at it, and Nexiel Verify, not this server, makes the real authorization decision, fresh, on every request (real Keycloak token introspection, checked for revocation instantly).
An early version of Stripe's own agent-toolkit let the calling codedecide which tools were "enabled," client-side, and a compromised or modified MCP client could still call a tool it was never supposed to have. Nexiel's Agent Toolkit checks that enforcement server-side instead: what an agent can do is decided entirely by what your API key's Keycloak-issued scopepermits, checked on Nexiel's server on every call, never by which tools happen to be registered on whatever MCP server your agent is talking to.
Every production API key requires an APPROVED KYB application first (see what KYB is and how to clear it). Once approved, go to your dashboard's API Keys page, choose product Nexiel Verify, and select scope Agent read-only. This restricts the key to session-creation and read-only routes; it can never reach the EUDI wallet callback, regardless of what any MCP tool tries to do. The dashboard shows the new credentials once:
client_id: nx-acme-corp-agent-key-<ts>
client_secret: ...
token_endpoint: https://auth.nexiel.io/realms/nexiel/protocol/openid-connect/tokenStore the secret now. It is never shown again. The key also appears in your key list going forward, labeled agent-readonly under its product, so you can confirm its scope or revoke it at any time.
Mint a short-lived access token from that key the normal OAuth2 client-credentials way. This is the value you put in the Authorization header, never the client secret itself:
curl -s -X POST https://auth.nexiel.io/realms/nexiel/protocol/openid-connect/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d grant_type=client_credentials \
-d client_id=nx-acme-corp-agent-key-<ts> \
-d client_secret=<clientSecret> \
| jq -r .access_tokenConfiguring an MCP-capable agent against agent-toolkit.nexiel.iois a one-time, no-install step: no repository to clone, nothing to build or run yourself. For Claude Code's (or any compatible client's) MCP config:
{
"mcpServers": {
"nexiel-agent-toolkit": {
"type": "http",
"url": "https://agent-toolkit.nexiel.io/mcp",
"headers": {
"Authorization": "Bearer ${NEXIEL_API_KEY}"
}
}
}
}NEXIEL_API_KEY is the access token from Step 1. Your MCP client reads it from your own environment and sends it as a bearer header on every call. Nothing else to install or configure: the server is stateless per-request and identifies you entirely from that token.
A coding agent calls create_age_verification_session the same way it calls any MCP tool: an initialize handshake, a tools/list, then the tool call itself. The response mirrors exactly what Nexiel Verify's own POST /v1/verify/sessions returns. The example below shows the real shape of that response:
{
"sessionId": "e3c79f37-9914-4d8b-a64a-621ebe04b8d8",
"templateVersion": "age-verification@2",
"authorizationRequest": {
"client_id": "https://verify.nexiel.eu",
"response_type": "vp_token",
"response_mode": "direct_post",
"response_uri": "https://compliance.nexiel.io/v1/verify/sessions/e3c79f37-9914-4d8b-a64a-621ebe04b8d8/responses",
"dcql_query": {
"credentials": [
{
"id": "av_age_over_18",
"format": "mso_mdoc",
"meta": {
"doctype_value": "eu.europa.ec.av.1"
},
"claims": [
{
"path": [
"eu.europa.ec.av.1",
"age_over_18"
]
}
]
},
{
"id": "pid_birthdate",
"format": "dc+sd-jwt",
"meta": {
"vct_values": [
"urn:eudi:pid:1"
]
},
"claims": [
{
"path": [
"birthdate"
]
}
]
}
],
"credential_sets": [
{
"options": [
[
"av_age_over_18"
],
[
"pid_birthdate"
]
],
"required": true
}
]
},
"nonce": "zBXjdv3b8dtgS1YcR8PraBCGsCZW4ohW9WrB3c70v9w",
"state": "B2tR6-36jnY9as2QLzPdpDqErgVOtwjd5JOsK-q_6HQ"
},
"authorizationRequestUri": "openid4vp://authorize?client_id=https%3A%2F%2Fverify.nexiel.eu&...(truncated)",
"expiresAt": "2026-07-05T14:49:53.884Z"
}Reading it back with get_verification_session, called immediately after creation:
{
"sessionId": "e3c79f37-9914-4d8b-a64a-621ebe04b8d8",
"clientId": "nx-acme-corp-agent-key-<ts>",
"checkType": "age-verification",
"templateVersion": "age-verification@2",
"status": "pending",
"createdAt": "2026-07-05T14:39:53.884Z",
"expiresAt": "2026-07-05T14:49:53.884Z",
"decision": null
}clientId above is the Keycloak-introspected identity behind the bearer token, not a value you supply (confirmation that the call is authorized by your own key, never a shared or default identity). Once a wallet completes the session (see the Verify API docs for that flow), the same tool call returns status: "completed" with the real decision, including the frozen decision artifact.
Both create_verification_session and create_age_verification_session accept an optional idempotencyKey. If you do not supply one, the tool generates one for you. An agent retrying a tool call after a network blip (a very real failure mode for an autonomous agent) can never accidentally start two sessions for what was meant to be one request.
Four tools: validate_en16931_invoice, generate_en16931_invoice_document, submit_invoice_to_sandbox_peppol, and check_peppol_participant_can_receive. They call @nexiel/einvoice's real 32-rule EN 16931 validator and UBL/CII serializers, and @nexiel/peppol-transport's real vendor-agnostic transport interface, directly. No Authorization header is read or required for any of them.
What these tools are not. Nexiel Invoice does not have a bearer-token-authenticated API yet, so there is no issue_invoice, no list_invoices, and no invoice-status tool here. This is on our roadmap. What these four tools give you today is real: the same EN 16931 compliance engine (validate/generate) and sandbox Peppol transport primitives the dashboard issuing flow itself uses, minus persistence. submit_invoice_to_sandbox_peppol's network field is always "sandbox", enforced structurally rather than merely documented, and nothing it submits is persisted anywhere a later call, or the dashboard, could look back up.
See the full tool reference: every tool, its parameters, its response shape, and an explicit PII/human-review (or, for the Invoice tools, persistence-scope) callout for each.