Tvarka Due Diligence

Lithuanian company data and remote client identification, provided as a legal service by a certified Lithuanian attorney-at-law (advokatas) who attests the provenance and integrity of every answer.

Two things follow from that and shape how you should use it:

• Answers are evidence, not scraped data. They can carry the attorney's qualified electronic signature and a qualified timestamp, so a signed answer still stands years later.
• Answers are billed per call, so do not poll blindly or retry on a whim. Read the billing rules below before writing a loop.

Connecting

MCP over Streamable HTTP at https://api.tvarka.pro/mcp, or REST at https://api.tvarka.pro/v1/.... Both take Authorization: Bearer <key> and cost the same.

claude mcp add --transport http tvarka-due-diligence https://api.tvarka.pro/mcp \
  --header "Authorization: Bearer $TVARKA_API_KEY"

Listing the tools needs no key. Calling one does.

Sandbox keys need nothing else - no agreement, no payment method, no linked entity - so a whole integration can be built before any paperwork. Ask at dd@tvarka.pro. A production key additionally needs acceptance of the Terms of Service, a signed engagement agreement, and a linked Tvarka entity that can be billed; until all three are in place it answers 402 (see Billing). The contract and the data shape are identical in both environments.

Company data

Every company tool takes one input, the Lithuanian legal-entity code (juridinio asmens kodas, 7 to 9 digits).

Choose the composite deliberately. If the user wants a general picture of a counterparty, get_due_diligence_report is one call and costs less than buying the parts. If they asked one narrow question, answer it with the one narrow tool rather than billing them for six answers they did not ask for.

A purpose is required for get_beneficial_owners and get_due_diligence_report, because beneficial-ownership data is served under the legitimate-interest regime and the stated purpose is logged. Pass the purpose the user actually has. Do not invent one to get past the parameter; if you do not know why they want it, ask.

interpret: true is available on lookup_company, get_beneficial_owners, get_seizures and get_due_diligence_report. It adds the attorney's standardized reading of what the data means under Lithuanian law, with statute citations, and it adds a fee. Use it when the user needs the legal meaning, not when they just need the facts.

Remote client identification

This is the asynchronous product, and it is the part most likely to be used wrongly. It answers: is the person I am dealing with really the manager, shareholder or beneficial owner the register says?

The register says who holds a role. The package makes that person prove they are that person: they sign a composed dossier with their own qualified electronic signature, the personal code inside their signing certificate is matched against the register record, and the attorney attests that verified correspondence. The result is one ASiC-E evidence container.

There is no video call, no selfie and no biometric processing anywhere in it. This is what Lithuanian anti-money-laundering law accepts as identification of a client who is not physically present.

The flow

1. create_kyc_package with the entity code, the claimed role (vadovas, dalyvis or naudos_gavejas) and a purpose. It returns immediately with an orderId and a ceremonyUrl.
2. Deliver the ceremonyUrl to the subject. Nothing happens until a human opens it and signs. Pass subjectEmail instead and Tvarka sends it.
3. Wait. get_kyc_package reports the state. A webhook to your callbackUrl, HMAC-signed with your webhook secret, is the equal alternative and the better one for anything long-running.
4. Fetch the container over REST at GET /v1/kyc-packages/{orderId}/artifact once the status is delivered. The bytes do not come back through the MCP tool.

Rules that matter

• Never promise the user a result in this turn. A human has to sign. Minutes to days is normal. Say so plainly rather than implying it is instant.
• Do not poll in a tight loop. Nothing changes until the subject acts, and polling burns tokens and time for no information. Poll on a human timescale, or use the webhook.
• A mismatch is a real answer, not an error. If the signer is not the register's role-holder, the order ends as a reported mismatch, no container is produced, and nothing is billed. Report it as a finding.
• get_kyc_package is the one tool keyed by order id, not by company code.

Billing

Per answered call. Never billed: a no-data answer, an upstream source outage, any failure on Tvarka's side. For identification, billed on delivery only — an order for a role nobody holds, a ceremony the subject abandons, and an identity mismatch all cost nothing.

Do not retry a failed call reflexively to "make sure". Errors are RFC 9457 application/problem+json, and the right response differs by type:

• 404 .../no-data - the source answered and holds nothing. Not billed. This is an answer, not a failure. Report it as "no record", and do not ask again; it will say the same thing.

• 502 .../upstream-unavailable - the source did not answer. Not billed. Worth exactly one retry, later.

• 402 .../payment-required - the account behind the production key cannot be billed right now. Nothing was pulled and nothing was charged. Do not retry in a loop: three of its four causes need a human to act, and looping will never clear them. Read detail and tell the user which:

  • no entity is linked to the key, or the entity has no enrolled payment method - they need to enroll one in Tvarka, or agree individual terms with dd@tvarka.pro;
  • an invoice is overdue and the account is locked - they need to settle it;
  • the usage ceiling is reached while an earlier payment settles - this one clears by itself, so retrying after the payment has cleared is correct.

  A sandbox key never sees a 402. If you are hitting one while testing, you are on a production key.

What this is not, and what you must not claim

• Not a credit score and not a risk rating. It is primary-source data with attested provenance.
• Not a document issued by a state institution.
• Identification here is not document verification. Nothing inspects a passport image, matches a face or tests liveness.
• It is not sanctions or politically-exposed-person screening. No such list is checked. If the user's obligation includes screening, tell them this does not cover it and that they need a screening tool alongside.
• Subjects whose qualified certificate carries a non-Lithuanian national identifier are out of scope for now.

If asked what the attestation proves, be precise: that the named attorney relayed this data unmodified from the named official source at the stated time, and for identification, that a specific qualified signature corresponds to a specific role as the register declares it. Not that the underlying facts are true.

Sandbox

Sandbox keys answer synthetic data at no cost, so an integration can be built before any paperwork. An identification order can be advanced to the outcomes an integrator must handle — an identity mismatch and an abandoned ceremony — but never to a delivered package. That would take a real qualified signature, and this platform does not mint test ones. Do not build a test that expects a delivered sandbox package; it cannot happen by design.