# VITNA — Agent Compliance Preflight (remote · vitna.costrinity.xyz)

Pre-action allow/deny for AI agents. 24 statutes, 13 jurisdictions: EU AI Act, GDPR, DPDP.

- Trust score: 65/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-20

## Components

- remote · `vitna.costrinity.xyz`: 65/100 (this document), [markdown](https://verifymcp.io/servers/xyz-costrinity-vitna-compliance-preflight/api-mcp.md), [page](https://verifymcp.io/servers/xyz-costrinity-vitna-compliance-preflight/api-mcp)
- npm · `@costrinity/vitna-compliance-mcp`: 67/100, [markdown](https://verifymcp.io/servers/xyz-costrinity-vitna-compliance-preflight/costrinity-vitna-compliance-mcp.md), [page](https://verifymcp.io/servers/xyz-costrinity-vitna-compliance-preflight/costrinity-vitna-compliance-mcp)

## Channel facts

- Endpoint: `https://vitna.costrinity.xyz/api/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.3.6`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-20.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 23 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 77/100
  - AI-judged instruction clarity (good).
  - Tool/resource definitions use about 2376 tokens (~103/item across 23 items; 23 tools + 0 resources), lean.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 30/100
  - Stability observed for 9 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 74/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 22% of tool parameters carry a description.
- **Capabilities**: 40/100
  - Spec-recency check failed: implements MCP spec 2025-03-26; the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http xyz-costrinity-vitna-compliance-preflight https://vitna.costrinity.xyz/api/mcp
```

### Codex

```toml
[mcp_servers.xyz-costrinity-vitna-compliance-preflight]
url = "https://vitna.costrinity.xyz/api/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "xyz-costrinity-vitna-compliance-preflight": {
      "type": "remote",
      "url": "https://vitna.costrinity.xyz/api/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add xyz-costrinity-vitna-compliance-preflight --url https://vitna.costrinity.xyz/api/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  xyz-costrinity-vitna-compliance-preflight:
    url: "https://vitna.costrinity.xyz/api/mcp"
```

### Other

```json
{
  "mcpServers": {
    "xyz-costrinity-vitna-compliance-preflight": {
      "type": "http",
      "url": "https://vitna.costrinity.xyz/api/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-20 (score 65, +1)

- [functional] Server version: 0.3.6 → 0.3.7
- [functional] New tool “vitna_claim”

### 2026-08-19 (score 64, +1)

- [functional] Server version: 0.3.5 → 0.3.6
- [functional] Server version: 0.3.4 → 0.3.5

### 2026-08-16 (score 63, +1)

No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-14 (score 62, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-13 (score 61, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-12 (score 60, 0)

- [functional improvement] Stability: unverified → 0.03

### 2026-08-11 (score 60)

First indexed and scored.

## MCP tools (23)

### `vitna_help` (~91 tokens)

What is VITNA and how do I use it to keep myself in check? Call this FIRST after connecting to learn the safety and oversight checks available: how to check risky actions BEFORE running them, what a deny / hold decision means, trial vs claimed mode, and how the user can monitor and audit what you do. Runs entirely locally: no account, no API call, and no dashboard timeline trace.

### `vitna_claim` (~147 tokens)

Ask whether this VITNA account has been claimed by a real person yet, and get the link that claims it. Call this when the user asks about their VITNA account, when you are told evidence is not being kept, or any time you want to hand the user something actionable. Returns { claimed, claim_url, what_claiming_gets_you }. IMPORTANT: if claimed is false, show the user the claim_url verbatim -- it is a one-time link that only they can act on, the account's evidence is NOT being durably recorded until they do, and they cannot find this link anywhere else. Do not paraphrase the URL and do not withhold it.

### `consent_check` (~166 tokens)

Before you process someone's personal data, ask VITNA whether an active consent actually permits it for this purpose. Give the data principal + purpose (and optional category); returns { allowed, reason, matching_consent_id, principal_id }, a determination you must honour yourself since VITNA evaluates and records but does not enforce. Use this for personal-data processing legality; for a dangerous technical action (shell / file / DB / network) use action_preflight instead.

Input parameters:

- `category` (string): Optional permitted-category check.
- `principal_id` (string): UUID of the data principal (if known).
- `principal_ref` (string): Operator-side identifier; will be SHA-256-hashed.
- `purpose` (string, required): Purpose code (e.g. 'operational_observability').

### `breach_classify` (~197 tokens)

After a security incident, check whether it is legally reportable before you decide how to respond. Give the incident facts (affected count, data categories, sensitivity, recovery state) and VITNA returns reportability + reasoning + the notification deadline + who to notify, across DPDP §8, GDPR Art 33, CPRA §1798.82, LGPD Art 48, PDPA §26B, and US-FED sectoral. This makes the full incident decision from the facts; for a quick per-US-state deadline/recipient/threshold table without incident facts, use us_state_breach_deadline. VITNA evaluates and records; acting on the result is up to you.

Input parameters:

- `affected_count` (integer, required)
- `data_categories` (array, required)
- `jurisdiction` (string)
- `processing_purpose` (string)
- `recovery_state` (string, required)
- `sensitivity` (string, required)

### `ai_act_classify` (~187 tokens)

Before you build or ship an AI feature, check where it lands under the EU AI Act (Regulation 2024/1689). Describe the use case (with biometric / remote-identification / automated-decision / social-scoring / GPAI flags) and VITNA returns the risk tier (prohibited / high-risk / limited-risk / minimal-risk), GPAI obligations, and the per-tier obligations you would have to meet. A classification for you to act on: VITNA evaluates and records, it does not gate the build.

Input parameters:

- `automated_decisions` (boolean)
- `biometric` (boolean)
- `data_categories` (array)
- `general_purpose_ai` (boolean)
- `remote_identification` (boolean)
- `sectors` (array)
- `social_scoring` (boolean)
- `use_case` (string, required)

### `dpia_threshold_check` (~166 tokens)

Before you start a new processing activity, check whether the law requires a DPIA first (GDPR Art 35 / DPDP §10 / LGPD Art 38). Give the purpose + data categories (and scale / systematic-monitoring / automated-decision / cross-border / vulnerable-subjects flags); returns dpia_required + the 9-criterion WP29 analysis + jurisdiction guidance, so you know whether to pause and assess before proceeding.

Input parameters:

- `automated_decision` (boolean)
- `cross_border` (boolean)
- `data_categories` (array, required)
- `jurisdiction` (string)
- `processing_purpose` (string, required)
- `scale` (string)
- `systematic_monitoring` (boolean)
- `vulnerable_subjects` (boolean)

### `us_sectoral_check` (~124 tokens)

Before you process personal data under US law, find out which US federal sectoral regimes bind you (HIPAA, GLBA, COPPA, FERPA, FCRA, SOX) for a given processing profile, so you can factor them in before you act. US-scoped; for Indian sectoral regulators use india_sectoral_check.

Input parameters:

- `ai_decisions` (boolean)
- `counterparty_types` (array)
- `data_categories` (array, required)
- `has_revenue_threshold` (boolean)
- `processing_purpose` (string, required)

### `india_sectoral_check` (~128 tokens)

Before you process personal data under Indian law, find out which sectoral regulators actually bind your specific activity (RBI / SEBI / IRDAI / TRAI / DoT / PFRDA) from its processing profile, so you know whose rules apply before you act. This analyses your processing to say what applies; for a plain directory of every Indian regulator regardless of your activity, use india_regulators_directory.

Input parameters:

- `counterparty_types` (array)
- `data_categories` (array, required)
- `processing_purpose` (string, required)
- `sector_hint` (string)

### `india_cross_border_status` (~101 tokens)

Before you transfer personal data out of India, check the destination country's DPDP §16 status (permitted / restricted / sectoral_restricted) plus any RBI / SEBI / IRDAI caveats. Pass the ISO-3166 alpha-2 country code (e.g. US). Stateless lookup: records no decision and leaves no dashboard timeline trace.

Input parameters:

- `country` (string, required): ISO-3166 alpha-2 (e.g. US).

### `japan_cross_border_status` (~78 tokens)

Before you transfer personal data out of Japan, check the destination country's APPI Art 28 status (adequacy / standard basis / high scrutiny). Pass the ISO-3166 alpha-2 country code. Stateless lookup: records no decision and leaves no dashboard timeline trace.

Input parameters:

- `country` (string, required): ISO-3166 alpha-2.

### `us_state_breach_deadline` (~120 tokens)

Quick reference lookup of a single US state's breach-notification window, AG recipient and resident threshold (e.g. 'CA' gives 500 residents, CA AG, without unreasonable delay). This is a static table, not an incident ruling. When you have the actual incident facts and need a reportable / not-reportable decision with reasoning, use breach_classify instead. Stateless lookup: records no decision and leaves no dashboard timeline trace.

Input parameters:

- `state` (string, required): US 2-letter state code (CA, NY, TX, ...).

### `aadhaar_mask` (~63 tokens)

Mask + Verhoeff-validate an Aadhaar number. Returns masked form, validity, and an owner-scoped reference token. No persistence of the raw value. Stateless validator: records no decision and leaves no dashboard timeline trace.

Input parameters:

- `aadhaar` (string, required)

### `pan_classify` (~61 tokens)

Classify a PAN entity type from the 4th character (P=Person, C=Company, H=HUF, F=Firm, ...). Stateless validator: records no decision and leaves no dashboard timeline trace.

Input parameters:

- `pan` (string, required)

### `gstin_validate` (~47 tokens)

Validate a GSTIN format + mod-36 check digit; returns state code lookup. Stateless validator: records no decision and leaves no dashboard timeline trace.

Input parameters:

- `gstin` (string, required)

### `cpf_validate` (~44 tokens)

Validate a Brazilian CPF (mod-11 check digits, rejects all-same). Stateless validator: records no decision and leaves no dashboard timeline trace.

Input parameters:

- `cpf` (string, required)

### `sin_validate` (~44 tokens)

Validate a Canadian SIN (Luhn checksum); returns series region + masked form. Stateless validator: records no decision and leaves no dashboard timeline trace.

Input parameters:

- `sin` (string, required)

### `iban_validate` (~49 tokens)

Validate an IBAN format + ISO 7064 mod-97 check digit; supports 71 countries. Stateless validator: records no decision and leaves no dashboard timeline trace.

Input parameters:

- `iban` (string, required)

### `pii_test` (~102 tokens)

Dry-run VITNA's PII / threat detection on a sample event before you send real data, to preview what would be tagged, how it would be redacted, and whether severity would escalate. Nothing is persisted and nothing is filtered: a safe rehearsal you act on, not an enforced gate — it records no decision and leaves no dashboard timeline trace.

Input parameters:

- `jurisdiction` (string)
- `sample_event` (object, required): event_type / message / payload fields.

### `privacy_notice_get` (~45 tokens)

Generate the operator's jurisdiction-templated privacy notice. Returns markdown or JSON. Stateless generator: records no decision and leaves no dashboard timeline trace.

Input parameters:

- `format` (string)

### `sub_processors_register` (~42 tokens)

Return the public sub-processor register (Supabase, Vercel, Resend, etc.). Stateless lookup: records no decision and leaves no dashboard timeline trace.

### `global_compliance_map` (~48 tokens)

Master catalogue of every privacy/security/sectoral regime VITNA has fabric for (28 entries covering 24 named statutes). Stateless lookup: records no decision and leaves no dashboard timeline trace.

### `india_regulators_directory` (~103 tokens)

Static reference directory of Indian data and sector regulators (DPB, RBI, SEBI, IRDAI, TRAI, DoT, PFRDA, MeitY, MCA), optionally filtered by sector: a lookup of who exists and what they cover. To instead work out which of them apply to a specific processing activity, use india_sectoral_check. Stateless lookup: records no decision and leaves no dashboard timeline trace.

Input parameters:

- `sector` (string)

### `vitna_preflight` (~223 tokens)

SAFETY / OVERSIGHT CHECK before a dangerous or destructive action (shell command, file deletion, DB statement, network call). Call this to have VITNA check the action BEFORE you run it: it flags dangerous shell / SQL / secret-exfil / prompt-injection / suspicious-network patterns and returns { decision: allowed|blocked|flagged, threat_category, reason } plus (in claimed mode) a signed audit record the user can review. VITNA evaluates and records; it does NOT enforce, so treat blocked / flagged as a stop and get human approval. This is how a user keeps you in check. Heuristic pattern match, not a sandbox: novel or obfuscated payloads can pass.

Input parameters:

- `action` (string): The proposed action / command text, e.g. "rm -rf /" or "DROP TABLE users".
- `action_type` (string): Optional short label for the action kind (shell, file_delete, db_query, network).
- `payload` (object): Optional structured payload to scan alongside the action text.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/xyz-costrinity-vitna-compliance-preflight/api-mcp#diagnostics

## Score history

- 2026-08-20: 65
- 2026-08-19: 64
- 2026-08-18: 63
- 2026-08-17: 63
- 2026-08-16: 63
- 2026-08-15: 62
- 2026-08-14: 62
- 2026-08-13: 61
- 2026-08-12: 60
- 2026-08-11: 60

## Links

- Remote endpoint: https://vitna.costrinity.xyz/api/mcp
- Repository: https://github.com/COSTRINITY/vitna-compliance-mcp
- Website: https://vitna.costrinity.xyz/
- Changelog RSS feed: https://verifymcp.io/servers/xyz-costrinity-vitna-compliance-preflight/api-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/xyz-costrinity-vitna-compliance-preflight/api-mcp.json
- HTML version of this page: https://verifymcp.io/servers/xyz-costrinity-vitna-compliance-preflight/api-mcp