Skip to main content
Glama

@lexvibe/mcp

lexvibe-mcp MCP server lexvibe-mcp MCP server Lexvibe MCP server

LexVibe MCP server — one-step legal compliance for vibe-coded apps (Lovable, Bolt, v0, Next.js, plain HTML). Wire it into your AI assistant (Claude Code, Claude Desktop, Cursor…) and it makes your app "legally ready" without you knowing the law: privacy policy, terms of service, cookie consent banner with real script blocking, and an EU AI Act risk check.

Not using an AI coding tool? The same checks run in the browser: paste your URL into the free website checker — no signup.

Tools

Tool

What it does

make_compliant

One step: scan → generate docs into /legal → install the banner snippet → classify EU AI Act risk.

check_compliance

Read-only readiness report: what was detected, what could be auto-derived, and which human facts are still missing. Run it again after adding any SDK to catch drift.

scan_project

Detect analytics, payments, generative AI, email collection, third parties and platforms (web / iOS / Android).

check_website

Free, no-signup compliance check of a deployed site by URL: per-vendor signals, recommendations and EU AI Act applicability (the same public checker as /check).

verify_snippet

Fetch a deployed URL and confirm the cookie-banner snippet is actually live in the served HTML (ok / missing / unknown).

generate_policies

Generate privacy policy / terms / AI disclosure, localized and tailored per market.

install_snippet

Insert the cookie-banner snippet before </head>; for JSX layouts it returns exact instructions instead.

check_ai_act

Classify EU AI Act risk and list the applicable obligations with deadlines.

claim_app

Create a REAL app in the user's LexVibe account: returns a link the user opens to sign in and confirm (valid 7 days).

get_claim_status

Poll a claim created with claim_app; once confirmed it returns the real app id, install snippet and policy URL.

Related MCP server: open-agreements

Typical use (natural language)

"Make my app legally compliant for the EU and the US."

One make_compliant call: the agent scans the project, writes the localized policies to /legal, installs the cookie-banner snippet in your HTML head and returns the EU AI Act classification plus next steps. You just review and approve.

Draft-first flow: start with check_compliance — it reports what the scan could figure out on its own and returns an agentPrompt your coding agent can answer by reading the repo (company entity, contact email, target markets), so there are no forms to fill.

No app id yet? The agent calls claim_app and hands you a link: open it, sign in and confirm — that creates the real app in your LexVibe account (hosted, auto-updated policies and consent proof linked to you). The agent then picks up the real app id via get_claim_status and replaces any YOUR_APP_ID placeholder automatically.

Keep your policies in sync with your code

Legal documents describe your app as it was when they were generated. Every SDK you add afterwards — payments, analytics, auth, AI — is a processing activity your documents don't cover yet. LexVibe calls this drift, and the MCP server is the sensor that lives inside your AI dev loop: the same assistant that adds the SDK can catch the compliance gap before you deploy.

Paste this standing rule into your assistant's project rules — AGENTS.md (Codex, Gemini CLI and most agents), CLAUDE.md, .cursorrules, .windsurfrules…:

After adding any SDK, analytics, payments, auth or AI integration to this project, run LexVibe's check_compliance tool and follow its recommendation.

When check_compliance reports processing activities that were added after your documents were generated, re-run generate_policies (or make_compliant) so the documents disclose the new processing. The same applies to the deployed site: check_website detects the trackers that actually ship to visitors, so you can catch drift the local scan can't see (scripts injected by a CMS, a tag manager, a no-code platform…). Claimed apps are also watched by LexVibe's other drift sensors (periodic site rechecks and the GitHub integration), and the remote check_website tool additionally returns a drift section for claimed apps comparing the live site against the baseline the documents were generated from.

Agent skill

skills/lexvibe-compliance/SKILL.md is an Agent Skill that tells your coding agent when to use this server (before a deploy, after adding an SDK) and how to report the result honestly. Drop the folder into your agent's skills directory — e.g. .claude/skills/ in Claude Code — next to the MCP server below.

Quickstart

npx -y @lexvibe/mcp   # or build from source: npm run build -w packages/mcp

Claude Code (.mcp.json in your project, or claude mcp add)

{
  "mcpServers": {
    "lexvibe": {
      "command": "npx",
      "args": ["-y", "@lexvibe/mcp"],
      "env": {
        "LEXVIBE_APP_ID": "your-app-id"
      }
    }
  }
}

Cursor (~/.cursor/mcp.json)

{
  "mcpServers": {
    "lexvibe": {
      "command": "npx",
      "args": ["-y", "@lexvibe/mcp"],
      "env": {
        "LEXVIBE_APP_ID": "your-app-id"
      }
    }
  }
}

Claude Desktop uses the same mcpServers structure in claude_desktop_config.json.

Codex CLI (~/.codex/config.toml)

Codex is the one client that does not use the mcpServers JSON above — its config is TOML:

codex mcp add lexvibe -- npx -y @lexvibe/mcp

Or by hand:

[mcp_servers.lexvibe]
command = "npx"
args = ["-y", "@lexvibe/mcp"]
env = { LEXVIBE_APP_ID = "YOUR_APP_ID" }

Project-scoped config lives in .codex/config.toml (trusted projects only).

Gemini CLI (~/.gemini/settings.json)

Same mcpServers shape as Cursor. For the remote server use httpUrl, not url: in Gemini CLI url means SSE, and this endpoint speaks Streamable HTTP only, so url fails without saying why.

{
  "mcpServers": {
    "lexvibe": { "httpUrl": "https://golexvibe.com/api/mcp" }
  }
}

Remote MCP (no install)

Browser-based agents that cannot run local processes — claude.ai / Claude Desktop connectors, ChatGPT connectors — can use the hosted remote server instead (Streamable HTTP, no auth):

https://golexvibe.com/api/mcp

The remote server has no filesystem access, so it exposes the remote-safe subset: check_website, check_store, generate_policies (template-based drafts, capped for anonymous callers), check_ai_act, get_install_snippet, plus claim_app / get_claim_status to create a real app in the user's account. Stdio-only clients can bridge to it with npx -y mcp-remote https://golexvibe.com/api/mcp.

Which integration to use, per platform

Platform

Integration

How

Claude Code

stdio (or remote)

claude mcp add lexvibe -- npx -y @lexvibe/mcp

Cursor / Windsurf / Cline / VS Code

stdio

mcpServers config with npx -y @lexvibe/mcp

Codex CLI

stdio (or remote)

codex mcp add lexvibe -- npx -y @lexvibe/mcp

Gemini CLI

stdio (or remote)

mcpServers in ~/.gemini/settings.json

Zed

stdio (or remote)

context_servers in settings.json

Claude Desktop / claude.ai

remote

Settings → Connectors → https://golexvibe.com/api/mcp

ChatGPT

remote

Settings → Connectors → https://golexvibe.com/api/mcp

Lovable / Bolt / v0 / Base44 / Replit

prompt (no MCP)

Paste the one-liner from https://golexvibe.com/prompt

Full per-platform setup guide: https://golexvibe.com/docs/integrations

Configuration

Variable

Default

Purpose

LEXVIBE_APP_ID

YOUR_APP_ID

Your LexVibe app id (links the snippet to your hosted policies)

LEXVIBE_API_URL

https://golexvibe.com

LexVibe instance that generates documents and classifies AI risk

LEXVIBE_CDN_URL

https://golexvibe.com

Host the widget script is served from (self-hosting only)

LEXVIBE_EVENTS_URL

LexVibe events endpoint

Override where anonymous tool-usage events are sent (self-hosting)

LEXVIBE_TELEMETRY

1

Set to 0 / false / off to disable usage telemetry

Usage analytics

Each tool call sends one anonymous mcp_tool_call event to LexVibe so your MCP usage shows up alongside your website in the Platform analytics dashboard (same event the hosted remote server already records, tagged source: "mcp_stdio" so the two channels are distinguishable).

  • Anonymous. The event carries only the tool name, the package version and — only when LEXVIBE_APP_ID is a real app id (a valid UUID) — that app id, so the events map to your app. Placeholders like your-app-id are ignored. Never your file paths, file contents, app name, emails or generated documents.

  • Non-blocking. It's fire-and-forget with a 3s timeout: it never delays, breaks or fails a tool call, even offline.

  • Opt-out. Set LEXVIBE_TELEMETRY=0 (or the de-facto DO_NOT_TRACK=1) to turn it off completely.

Side effects: scan_project, check_compliance, check_website, verify_snippet, check_ai_act and get_claim_status are read-only (check_website, the AI Act check and the claim poll call the LexVibe API; verify_snippet fetches the URL you pass it — public http(s) hosts only, with the same anti-SSRF validation the platform uses). generate_policies calls the API and returns Markdown. install_snippet edits one file on your local filesystem (only when it contains </head>). make_compliant does both: it calls the API and writes files (/legal/*.md plus the snippet in your HTML head). claim_app creates a pending claim in LexVibe; the app itself is only created when the user confirms the link while signed in.

Learn more

  • LexVibe — hosted legal documents and a cookie banner with real script blocking, for web and mobile apps.

  • Free website checker — paste a URL and see which documents and consent your site needs. No signup.

  • Compliance guides — each privacy law applied to the kind of product you built (SaaS, marketplace, mobile app, AI tool). Also in Spanish.

  • Privacy and AI law reference — every framework with its effective date, the rights it grants and its primary sources, also available as an open dataset (CC BY 4.0).

  • Integration guides — setup for Claude, Cursor, Codex, Gemini CLI, ChatGPT, Lovable, Bolt, v0 and more.

Available Tools

10 tools
check_ai_actA
Read-only
Inspect

Classify a product's risk level under the EU AI Act — minimal, limited, high or prohibited — and return the applicable obligations, each with its compliance deadline (limited-risk transparency duties apply from Aug 2, 2026; Annex III high risk from Dec 2, 2027). The boolean parameters fall into three groups, all optional and defaulting to the safest 'not applicable' value: (1) transparency triggers — usesAI, interactsWithPeople, generatesContent, automatedDecisions; (2) the eight prohibited practices of art. 5 — socialScoring, realtimeBiometricPublic + realtimeBiometricLawEnforcement, emotionRecognitionWorkEducation, biometricCategorisationSensitive, untargetedFaceScraping, manipulativeOrExploitative, individualPredictivePolicing; (3) high-risk triggers — embeddedInRegulatedProduct, annexIII domains. Answer from what you know about the product (scan_project's suggestedAnswers.usesGenerativeAI maps to usesAI + generatesContent); leave unknowns at their defaults, which never over-report risk. Returns {level, headline, explanation, obligations: [{title, description, deadline}]}. Read-only, no signup; requires network access to the LexVibe API (errors return {error} with isError). Use it when the user asks whether the EU AI Act applies to them or after adding an AI feature; make_compliant already includes a basic version of this check.

Inputs: usesAI, annexIII, socialScoring, generatesContent, +10 more.

check_complianceA
Read-only
Inspect

Read-only compliance readiness check. Run this after adding any SDK, analytics, payment, auth or AI integration — it detects processing activities your legal documents don't cover yet. It scans the project, detects platforms and data processing, auto-derives what it can (app name, legal entity, contact email) and reports which human facts are still missing (including target markets). Returns {platforms, detected, derived, provided, missing, ready, agentPrompt}: ready is true only when no human fact is missing, and agentPrompt is a prompt you (the dev agent) can answer from the repo, so document generation needs no forms. Never modifies files; errors if dir does not exist or is not a project root. Call it before make_compliant when you want to confirm facts first; re-run it with the answers as arguments until ready is true.

Inputs: dir (required), entity, appName, markets, +1 more.

check_websiteA
Read-only
Inspect

Free, no-signup compliance check of a DEPLOYED website by URL (the same public checker as the LexVibe /check page). Fetches the live page server-side and detects tracking/processing that actually ships to visitors — analytics, marketing pixels, payments, generative AI, email capture, third parties. Returns {url, signals: [{signal, vendors}], recommendations: [{id, title, reason}], aiAct} — which documents/banner the site needs and whether the EU AI Act applies. Read-only and rate-limited (a burst of calls returns an error asking to wait a minute). Complements scan_project (which reads the local source): use check_website after deploying, or for a site whose code you don't have.

Inputs: url (required).

claim_appAInspect

Create a REAL LexVibe app in the user's account (replaces the YOUR_APP_ID placeholder). Returns {claimUrl, code, expiresAt}: show claimUrl to the user so they can sign in and confirm — the link stays valid for 7 days, so the user can open it later. After they confirm, call get_claim_status with code to retrieve the real app id and install snippet. Requires url or appName (errors otherwise). Use this whenever no real LEXVIBE_APP_ID is configured, so hosted policies, consent proof and auto-updates get linked to the user's account; creates nothing until the user confirms the link.

Inputs: url, facts, answers, appName, +3 more.

generate_policiesA
Read-only
Inspect

Generate the legal documents (privacy policy, terms of service and, if applicable, an AI disclosure) localized and tailored to the target markets' frameworks (GDPR, UK GDPR, CCPA/CPRA, PIPEDA, LGPD…). Returns {documents: [{docType, locale, content, source}]} where content is Markdown and source is 'ai' or 'template' (template ⇒ not yet personalized — tell the user). Documents are returned only, never written to disk (make_compliant writes them to /legal) and nothing is persisted server-side. Run scan_project first and pass its suggestedAnswers as answers so the documents disclose the right processing; requires network access to the LexVibe API.

Inputs: appName (required), markets (required), entity, answers, +2 more.

get_claim_statusA
Read-only
Inspect

Check whether the user has confirmed a claim created with claim_app. Returns {status: 'pending' | 'expired' | 'claimed', …}. While 'pending', wait a few seconds and call again (the link stays valid for 7 days; 'expired' ⇒ create a new claim). Once 'claimed' it adds the REAL appId, the install snippet, the hosted policyUrl, published (if false, do NOT install the snippet yet — the policy page would be a dead link until the user publishes from their dashboard) and a pending list of details the code can't know (e.g. the controller's legal name): replace any YOUR_APP_ID placeholder snippet with the real one and ask the user for the pending items. Errors on an unknown code.

Inputs: code (required).

install_snippetA
Idempotent
Inspect

Insert the LexVibe cookie-banner + hosted-policies snippet into an HTML file, right before . By default the banner is themed to match the app's own colors, fonts and radius (detected from its stylesheets). Idempotent: if the snippet is already in the file, nothing changes. If the file has no literal (e.g. a Next.js App Router layout.tsx), it does NOT modify the file: it returns the snippet plus exact instructions for you (the dev agent) to add it as JSX — it never corrupts user files. After deploying, confirm with verify_snippet that the snippet is live.

Inputs: file (required), lang, appId, theme, +2 more.

make_compliantAInspect

One-step legal compliance: scan the project, generate privacy policy / terms / cookie & AI disclosures (written as Markdown to /legal), install the cookie-banner snippet before (web only; skipped for native apps, and JSX layouts get manual instructions instead of being modified), and classify EU AI Act risk. Use this first when the user asks to make their app legally compliant, GDPR-ready, or to add a privacy policy or cookie banner; use check_compliance instead for a read-only report. Returns {done, filesWritten, documents, source, snippet, aiAct, missingFacts, agentPrompt, nextSteps} — if source is 'template' or missingFacts is non-empty, answer the agentPrompt and re-run with appName/entity/contactEmail/markets for complete documents. Aborts without writing anything if dir does not exist or is not a project root.

Inputs: dir (required), lang, appId, accent, +5 more.

scan_projectA
Read-only
Inspect

Read-only scan of a local project (dependencies + source code + mobile manifests). Detects data processing relevant to legal compliance — analytics, payments, generative AI (distinguishing user-facing AI from server-side-only AI), email collection, third-party sharing — and returns {signals, suggestedAnswers, facts, locales, platforms}: per-vendor signals, compliance flags in suggestedAnswers, structured facts (auth methods, payments channel, AI flags, tracking/IDFA, device permissions), the locales the app supports and the product platforms (web / iOS / Android). Run it first: pass suggestedAnswers to generate_policies, and facts, locales and signals to claim_app so the generated documents are anchored in evidence. Never modifies files; errors if dir does not exist or is not a project root. For a deployed site whose code you don't have, use check_website instead.

Inputs: dir (required).

verify_snippetA
Read-only
Inspect

Verify that the LexVibe cookie-banner snippet is actually LIVE on a deployed site: fetches the public URL and looks for the widget marker in the served HTML. Run it after deploying (install_snippet edits local files — this confirms the change reached production). Only public http(s) hosts are allowed — localhost, private-network and reserved addresses are rejected. Returns {status: 'ok' | 'missing' | 'unknown'}. If 'missing', the snippet was not found: check that the deploy included the change, or re-run install_snippet and deploy again.

Inputs: url (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.6/5.0

    Scored across 10 tools

    Disambiguation4/5

    Most tools target clearly distinct actions (scan_project, check_website, generate_policies, install_snippet, verify_snippet, check_ai_act). The potential overlaps — check_compliance vs make_compliant vs scan_project vs check_website — are explicitly differentiated in the descriptions (read-only vs write, local source vs deployed URL), so an agent can tell them apart, though the cluster of 'check*' tools requires careful reading.

    Naming Consistency5/5

    All ten tools follow a consistent snake_case verb_noun pattern (claim_app, check_compliance, generate_policies, install_snippet, verify_snippet, scan_project). The convention is uniform throughout with no mixed casing or stylistic drift.

    Tool Count5/5

    Ten tools is well-scoped for a legal-compliance server spanning scan, generate, install, verify, and app-claim workflows. Each tool earns its place with no redundant or filler entries.

    Completeness4/5

    The surface covers a full lifecycle: scan_project → generate_policies → install_snippet → verify_snippet, plus claim_app/get_claim_status, check_website, check_ai_act, and the one-shot make_compliant. Minor gaps exist (no snippet removal, no update/delete of previously generated documents), but agents can work around these.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers