Skip to main content
Glama
marcosnovo

@lexvibe/mcp

by marcosnovo
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Hybrid

@lexvibe/mcp

lexvibe-mcp MCP server lexvibe-mcp 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.

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 (30 min).

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: LegalForge MCP Server

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.

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.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
usesAINoDoes the product use AI at all (LLM calls, recommendations, computer vision…)? false ⇒ minimal risk, the AI Act does not apply.
annexIIINoAnnex III high-risk domains the system operates in: biometrics, critical (infrastructure), education, employment (HR/hiring), essential (credit, insurance, benefits), law (enforcement), migration, justice. Empty if none apply.
socialScoringNoDoes it score people's social behavior or traits causing detrimental treatment in unrelated contexts, or disproportionate to the behavior (art. 5.1.c)? Prohibited. A seller rating or fitness points app is NOT this.
generatesContentNoDoes it generate text, images, audio or video shown to users? Triggers the art. 50 duty to label AI-generated content.
automatedDecisionsNoDoes it make automated decisions with legal or similarly significant effects on people (credit, hiring, admissions…)? Adds GDPR art. 22 duties; high risk only if an Annex III domain applies.
interactsWithPeopleNoDo people interact directly with the AI (chatbot, voice assistant…)? Triggers the art. 50 duty to disclose they are talking to an AI.
untargetedFaceScrapingNoDoes it untargetedly scrape facial images from the internet or CCTV footage to build or expand a face-recognition database (art. 5.1.e)? Prohibited. Matching a user's own consented selfie against their own ID photo is NOT this.
realtimeBiometricPublicNoReal-time remote biometric identification in publicly accessible spaces (e.g. live face recognition)? High risk (Annex III biometrics) — prohibited only when combined with realtimeBiometricLawEnforcement.
embeddedInRegulatedProductNoIs the AI a safety component embedded in an Annex I regulated product (toys, machinery, medical devices…)? High risk via art. 6.1, deadline Aug 2, 2028.
manipulativeOrExploitativeNoDoes it use subliminal techniques beyond a person's consciousness, or exploit a known vulnerability (age, disability, specific social or economic situation) to materially distort behavior and cause harm — e.g. dark patterns targeting a diagnosed gambling addiction (art. 5.1.a-b)? Prohibited. Ordinary persuasive marketing or UX nudges aimed at the general population are NOT this.
individualPredictivePolicingNoPredicting an individual's criminal risk based solely on profiling or personality traits (art. 5.1.d)? Prohibited.
emotionRecognitionWorkEducationNoDoes it infer emotions (frustration, attention, mood…) from employees at work or students in education, e.g. to flag disengaged staff or bored students (art. 5.1.f)? Prohibited. Emotion inference on end users of a public consumer product (not their employees/students) is NOT this.
realtimeBiometricLawEnforcementNoOnly if realtimeBiometricPublic: is it used for LAW ENFORCEMENT purposes? That combination is prohibited (art. 5.1.h) and already in force.
biometricCategorisationSensitiveNoDoes it use biometric data (face, voice, gait…) to infer sensitive attributes — race, political opinion, religion, trade-union membership, sexual orientation (art. 5.1.g)? Prohibited. Ordinary face-unlock or liveness checks that don't infer these attributes are NOT this.

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavioral context beyond annotations: read-only, no signup required, requires network access to LexVibe API, error returns {error} with isError. It also explains parameter defaults default to the safest 'not applicable' value, which aligns with destructiveHint=false. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured: starts with core purpose, then parameter grouping, return format, and usage notes. It front-loads the main action and avoids redundancy. Every sentence earns its place, though brevity could be improved.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 14 boolean parameters and no output schema, the description adequately explains the return structure ({level, headline, explanation, obligations}) and each parameter's impact. It also covers error handling and network requirements, making the tool usable without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameter descriptions exist. The tool description adds value by grouping parameters into three categories (transparency triggers, prohibited practices, high-risk triggers) and mapping to scan_project's outputs (e.g., usesGenerativeAI maps to usesAI and generatesContent). This enhances understanding beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool classifies a product's risk level under the EU AI Act, returning risk levels (minimal, limited, high, prohibited) and obligations with deadlines. It also differentiates from siblings like scan_project and make_compliant, noting mapping of scan_project's outputs to parameters and that make_compliant includes a basic version of this check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage guidance: use when the user asks whether the EU AI Act applies to them or after adding an AI feature. It also explains when not to use (leave unknowns at defaults) and mentions an alternative (make_compliant already includes a basic version of this check).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
dirYesPath of the project root to analyze (absolute paths are safest).
entityNoData controller / legal entity, if already known (overrides the derived one).
appNameNoOverride the auto-derived app name.
marketsNoRegions where the app has users. Without them `ready` can never be true (markets are a required human fact).
contactEmailNoPrivacy contact email, if already known (overrides the derived one).

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint=true, destructiveHint=false), description adds key behaviors: never modifies files, errors on invalid dir/path, and explains return value structure including 'agentPrompt' for dev agent. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and usage; every sentence adds value. Slightly long but dense with information, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description fully explains return object fields and 'ready' condition. Covers error conditions, iterative workflow, and required parameters. Complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions. Description adds context like 'markets are a required human fact' and 'overrides the derived one' for entity/appName, enriching meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb ('Read-only compliance readiness check') and resource ('project'), with specific use case after adding integrations. Distinguishes itself from sibling tools like make_compliant by indicating it's a precursor check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use ('after adding any SDK, analytics, payment, auth or AI integration') and when not to (implies not for full generation, as call before make_compliant). Provides iterative re-run strategy until 'ready' is true.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPublic URL (or bare domain) of the deployed site, e.g. https://myapp.com or myapp.com. Must be publicly reachable.

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations indicating read-only and non-destructive, the description explains server-side fetching, detection of tracking/processing, and the output structure. It also notes rate-limit behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with key benefits, then details on functionality and usage. Every sentence adds value, no redundancy. Structure is logical and concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given simple input (one parameter) and no output schema, the description fully explains the return structure and behavior. It also references sibling tools and usage context, making it self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already fully describes the 'url' parameter with examples and requirement. The tool description adds no new parameter information beyond restating that it's a public URL, so baseline 3 is appropriate given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a compliance check of a deployed website by URL, distinguishing itself from sibling scan_project which reads local source. It specifies the output format and the context of use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use: after deploying or for sites without source code. Mentions rate-limiting and that it complements scan_project, guiding the agent on alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 expires in 30 minutes. 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoPublic URL of the app: a website URL when answers.platformType includes 'web', or the App Store / Google Play listing URL when it's mobile-only (ios/android without web). LexVibe scans whichever kind of URL is provided on confirmation.
factsNoscan_project's `facts` object as-is: { authMethods: (apple/google/email/other)[], payments: apple_iap/google_play/stripe/other/none, ai: { userFacing, serverSide, processesPersonalData, providers }, tracking: { idfa, att, adSdks }, devicePermissions: string[] }. Pass it through unchanged — it anchors the generated documents in evidence.
answersNoCompliance flags you already know (pass scan_project's suggestedAnswers): usesAnalytics, processesPayments, usesGenerativeAI, collectsEmails, sharesWithThirdParties, platformType, companyEntity, contactEmail…
appNameNoApp / business name (required if no url is provided).
localesNoscan_project's `locales` — ISO 639-1 language codes the app actually supports, e.g. ['en', 'es'].
marketsNoRegions where the app has users; each market pack cites its own frameworks: eu → GDPR/ePrivacy, uk → UK GDPR/PECR, us → CCPA/CPRA, ca → PIPEDA, latam → LGPD…; 'global' is NOT a union of the others — it only cites generic OECD international privacy best practices, for users outside every listed market. To cover several specific frameworks, list each market explicitly, e.g. ['eu', 'us', 'latam']. Defaults to [eu].
signalsNoscan_project's `signals` — detected processing with vendor names.

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the claim-link expiration (30 minutes), the need for user confirmation, and the follow-up call to get_claim_status. This adds significant value beyond annotations by explaining the mutation's deferred nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Around 150 words, covering all key points. Could be slightly more concise, but information density is good and front-loaded with core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with nested objects and no output schema, the description covers the workflow, return values, and motivation. Lacks error cases or rate limits, but openWorldHint allows flexibility.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good parameter descriptions, but the description adds a crucial constraint: 'Requires url or appName (errors otherwise)', which is not in the schema's required list. This provides decision guidance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it creates a real LexVibe app, replaces a placeholder, and returns a claim URL with code and expiry. It distinguishes from sibling tools like get_claim_status by describing the post-confirmation step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this whenever no real LEXVIBE_APP_ID is configured' and requires either `url` or `appName`. Provides clear context for when to invoke this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
entityNoData controller / legal entity (person or company legally responsible), e.g. 'Acme Labs S.L.'. If omitted, the documents keep a [to complete] placeholder.
answersNoCompliance flags; pass scan_project's suggestedAnswers. Recognized keys: usesAnalytics, processesPayments, usesGenerativeAI, collectsEmails, sharesWithThirdParties, platformType.
appNameYesApp / business name shown in the documents, e.g. 'Acme Notes'.
localesNoLanguages to generate the documents in (ISO 639-1). Defaults to the markets' main languages; anonymous calls are capped at 3 locales. Pass scan_project's `locales` to match the languages the app actually ships.
marketsYesRegions where the app has users (at least one). Each market pack cites its own frameworks: eu → GDPR/ePrivacy, uk → UK GDPR/PECR, us → CCPA/CPRA, ca → PIPEDA, latam → LGPD…; 'global' is NOT a union of the others — it only cites generic OECD international privacy best practices, for users outside every listed market. To cover several specific frameworks, list each market explicitly, e.g. ['eu', 'us', 'latam'].
contactEmailNoPrivacy contact email published in the documents. If omitted, a [to complete] placeholder is left.

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds key details: documents are returned only, never persisted server-side, and template source means not yet personalized. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single focused paragraph front-loaded with purpose. Every sentence adds value: purpose, prerequisite, behavior, return format, and distinction from sibling. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters, nested objects, and no output schema, the description covers all critical aspects: return structure (documents array with fields), special values (template source), prerequisite (scan_project), and network requirement. It compensates fully for the missing output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, each parameter has a description. The description adds contextual meaning: explains relationship between 'answers' and 'scan_project', clarifies 'global' market is not a union, and describes the return format. This adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates legal documents (privacy policy, terms of service, AI disclosure) with localization and market-specific frameworks. It distinguishes from siblings like 'make_compliant' and 'scan_project', providing a specific verb and resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to 'Run scan_project first and pass its suggestedAnswers as `answers`', indicates the tool requires network access to an API, and clarifies that persistence is handled by another tool ('make_compliant'). This provides clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 expires in 30 minutes; '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.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesThe claim code returned by claim_app (not the URL — the `code` field).

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, and the description reinforces this by explaining the tool only reads status. It adds critical behavioral context like expiration timing, condition for not installing snippet, and error handling for unknown codes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Despite being lengthy, every sentence provides essential information. The structure flows logically from status outcomes to action items, and there is no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description fully compensates by describing the return structure and behavior for each case. It covers the lifecycle from pending to claimed, including edge cases like expired and errors.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the 'code' parameter, but the description adds the crucial clarification that it must be the `code` field from claim_app, not the URL. This adds value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks claim status and specifies the different return states and their implications. It distinguishes itself from siblings like claim_app (which creates the claim) by focusing on status checking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit instructions on how to handle each status: wait and retry for pending, recreate for expired, and detailed steps for claimed including not installing snippet if published is false. This gives clear when-to-use and follow-up actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
fileYesPath of the file to install into (index.html, app/layout.tsx…).
langNoForce the banner's language as an ISO 639-1 code, e.g. 'en' or 'es' (one of the 12 LexVibe locales). Defaults to the page's own language.
appIdNoLexVibe app id, e.g. from claim_app/get_claim_status (defaults to the LEXVIBE_APP_ID env var; without either, the YOUR_APP_ID placeholder is used and flagged).
themeNoauto (default): match the banner to this app's colors, fonts and radius. off: LexVibe default look.
accentNoBanner accent color as a CSS hex value, e.g. #4f46e5. Defaults to the color detected from the app's own styles (see `theme`).
positionNoWhere the banner sits on screen: bottom (full-width bar), bottom-left or bottom-right (floating card in that corner). Defaults to bottom.

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description significantly extends beyond annotations. It discloses idempotency, safe handling of non-HTML files (no corruption), behavior when </head> is missing (returns instructions instead of modifying), and the need for deployment verification. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (5-6 sentences) with a clear front-loaded main action. Every sentence adds essential information, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description fully explains tool behavior: what it does, idempotency, handling of edge cases (non-HTML files), and follow-up action (verify_snippet). Complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline 3. The description adds minimal extra meaning beyond schema defaults (e.g., lang defaults to page language, appId from env). No substantial additional semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool inserts a LexVibe cookie-banner and hosted-policies snippet into an HTML file before </head>. It distinguishes itself from sibling tools like verify_snippet, scan_project, etc., which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (installing snippet) and mentions post-installation verification with verify_snippet, but does not explicitly list when to use or not use this tool versus alternatives. Still clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
dirYesPath of the project root to analyze (absolute paths are safest).
langNoForce the banner's language as an ISO 639-1 code, e.g. 'en' or 'es' (one of the 12 LexVibe locales). Defaults to the page's own language.
appIdNoLexVibe app id (defaults to the LEXVIBE_APP_ID env var). Without a real id the snippet uses the YOUR_APP_ID placeholder and the result tells you to call claim_app.
accentNoBanner accent color as a CSS hex value, e.g. #4f46e5. Defaults to the LexVibe accent.
entityNoData controller / legal entity, if already known (overrides the derived one).
appNameNoApp / business name. If omitted, it's derived from the repo (package.json / LICENSE).
marketsNoRegions where the app has users; they decide which frameworks the documents cover (eu → GDPR, uk → UK GDPR, us → CCPA/CPRA…). Defaults to ["eu"] — confirm with the user before accepting that default.
positionNoWhere the banner sits on screen: bottom (full-width bar), bottom-left or bottom-right (floating card in that corner). Defaults to bottom.
contactEmailNoPrivacy contact email, if already known (overrides the derived one).

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses detailed behavior including: writes to <dir>/legal, installs cookie banner only for web apps, skips for native apps, gives manual instructions for JSX layouts, aborts if dir doesn't exist. It also explains the return value structure and the conditional re-run logic. This goes well beyond the annotations (readOnlyHint: false, openWorldHint: true) and provides complete transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph that effectively front-loads the main purpose and then provides detailed caveats and return info. For the complexity involved, it is reasonably concise, though it could potentially be broken into bullet points for easier scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema is provided, but the description fully documents the return value structure and explains how to interpret the fields (e.g., agentPrompt, missingFacts). It covers all major behaviors (document generation, banner installation, AI Act classification, conditional execution) and edge cases (JSX, native apps, missing dir). Given the tool's complexity, this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining defaults (appId from env var, markets to eu), constraints, and the need to confirm the default markets with the user. It also clarifies when parameters are optional (e.g., appName derived from repo). This extra context justifies a score of 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with 'One-step legal compliance' and enumerates specific actions (scan, generate documents, install cookie banner, classify AI Act risk). It distinguishes from sibling check_compliance by explicitly stating when to use each, making the purpose crystal clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('when user asks to make app legally compliant, GDPR-ready, or to add privacy policy or cookie banner') and when to use check_compliance instead ('for a read-only report'). Also explains abort conditions and re-run triggers, providing comprehensive usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
dirYesPath of the project root to analyze (absolute paths are safest).

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds further context: 'Never modifies files', error conditions (dir does not exist or not a project root), and details about return structure. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with key action and purpose. It is slightly verbose but each sentence adds meaningful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description fully explains the return format and fields. It also covers prerequisites, post-processing steps, and siblings. Complete for a single-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single param 'dir' described. Description adds value by explaining error behavior if dir is invalid and suggesting using absolute paths.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a read-only scan of a local project for legal compliance detection. It specifies the resource (local project) and action (scan), and distinguishes from sibling tool check_website for deployed sites.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to 'Run it first' and describes how to pass results to generate_policies and claim_app. Also provides alternative: use check_website for deployed sites without code access.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPublic URL (or bare domain) of the deployed site to verify, e.g. https://myapp.com or myapp.com. Must be publicly reachable.

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, consistent with the read-only nature. The description adds detail on behavior: fetches the public URL, looks for widget marker, validates URL (rejects private/localhost). It also explains the exact return format and meanings. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: 4 sentences covering purpose, usage context, constraints, and return values. It is front-loaded with the main action. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple verification tool with one parameter and no output schema, the description is complete. It covers what, why, when, constraints, and result interpretation. Annotations handle safety, so the description meets all needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already has a good description for the url parameter (100% coverage). The tool description adds further constraint: 'Only public http(s) hosts are allowed — localhost, private-network and reserved addresses are rejected,' which is not in the schema. This adds meaningful context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies that the LexVibe cookie-banner snippet is live on a deployed site. It distinguishes from the sibling tool install_snippet by noting that install_snippet edits local files while this confirms production. The verb 'verify' and specific resource 'snippet live on deployed site' are precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use ('Run it after deploying') and gives constraints ('Only public http(s) hosts allowed'). It provides alternative actions if the snippet is missing ('check that the deploy included the change, or re-run install_snippet and deploy again'). This is comprehensive guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.12
    • Changedclaim_app1 field changed
      • changedInput schema / properties / url / description
        Previous value: -"Public URL of the app (website or App Store / Google Play listing). LexVibe scans it on confirmation."New value: +"Public URL of the app: a website URL when answers.platformType includes 'web', or the App Store / Google Play listing URL when it's mobile-only (ios/android without web). LexVibe scans whichever kind of URL is provided on confirmation."
  2. 6 tool updatesv0.1.11
    • Changedcheck_compliance1 field changed
      • changedInput schema / properties / dir / description
        Previous value: -"Project root path."New value: +"Path of the project root to analyze (absolute paths are safest)."
    • Changedclaim_app3 fields changed
      • changedInput schema / properties / facts / description
        Previous value: -"scan_project's `facts` (structured evidence: auth methods, payments, AI flags, tracking, device permissions). Pass it through unchanged — it anchors the generated documents in evidence."New value: +"scan_project's `facts` object as-is: { authMethods: (apple/google/email/other)[], payments: apple_iap/google_play/stripe/other/none, ai: { userFacing, serverSide, processesPersonalData, providers }, tracking: { idfa, att, adSdks }, devicePermissions: string[] }. Pass it through unchanged — it anchors the generated documents in evidence."
      • changedInput schema / properties / locales / description
        Previous value: -"scan_project's `locales` — languages the app actually supports."New value: +"scan_project's `locales` — ISO 639-1 language codes the app actually supports, e.g. ['en', 'es']."
      • changedInput schema / properties / markets / description
        Previous value: -"Regions where the app has users. Defaults to [eu]."New value: +"Regions where the app has users; each market pack cites its own frameworks: eu → GDPR/ePrivacy, uk → UK GDPR/PECR, us → CCPA/CPRA, ca → PIPEDA, latam → LGPD…; 'global' is NOT a union of the others — it only cites generic OECD international privacy best practices, for users outside every listed market. To cover several specific frameworks, list each market explicitly, e.g. ['eu', 'us', 'latam']. Defaults to [eu]."
    • Changedgenerate_policies1 field changed
      • changedInput schema / properties / markets / description
        Previous value: -"Regions where the app has users (at least one). Each market pack cites its frameworks: eu → GDPR/ePrivacy, uk → UK GDPR/PECR, us → CCPA/CPRA, ca → PIPEDA, latam → LGPD…; 'global' covers all of them at the highest common bar."New value: +"Regions where the app has users (at least one). Each market pack cites its own frameworks: eu → GDPR/ePrivacy, uk → UK GDPR/PECR, us → CCPA/CPRA, ca → PIPEDA, latam → LGPD…; 'global' is NOT a union of the others — it only cites generic OECD international privacy best practices, for users outside every listed market. To cover several specific frameworks, list each market explicitly, e.g. ['eu', 'us', 'latam']."
    • Changedinstall_snippet2 fields changed
      • changedInput schema / properties / lang / description
        Previous value: -"Force the banner language (default: the page's)."New value: +"Force the banner's language as an ISO 639-1 code, e.g. 'en' or 'es' (one of the 12 LexVibe locales). Defaults to the page's own language."
      • changedInput schema / properties / position / description
        Previous value: -"Where the banner sits on screen."New value: +"Where the banner sits on screen: bottom (full-width bar), bottom-left or bottom-right (floating card in that corner). Defaults to bottom."
    • Changedmake_compliant3 fields changed
      • changedInput schema / properties / dir / description
        Previous value: -"Project root path."New value: +"Path of the project root to analyze (absolute paths are safest)."
      • changedInput schema / properties / lang / description
        Previous value: -"Force the banner language (default: the page's)."New value: +"Force the banner's language as an ISO 639-1 code, e.g. 'en' or 'es' (one of the 12 LexVibe locales). Defaults to the page's own language."
      • changedInput schema / properties / position / description
        Previous value: -"Where the banner sits on screen."New value: +"Where the banner sits on screen: bottom (full-width bar), bottom-left or bottom-right (floating card in that corner). Defaults to bottom."
    • Changedverify_snippet1 field changed
      • changedInput schema / properties / url / description
        Previous value: -"Public URL (or bare domain) of the deployed site to verify."New value: +"Public URL (or bare domain) of the deployed site to verify, e.g. https://myapp.com or myapp.com. Must be publicly reachable."
  3. 7 tool updatesv0.1.10
    • Changedcheck_ai_act15 fields changed
      • addedInput schema / properties / annexIII / description
        Added value: +"Annex III high-risk domains the system operates in: biometrics, critical (infrastructure), education, employment (HR/hiring), essential (credit, insurance, benefits), law (enforcement), migration, justice. Empty if none apply."
      • addedInput schema / properties / annexIII / items / enum
        Added value: +[
+  "biometrics",
+  "critical",
+  "education",
+  "employment",
+  "essential",
+  "law",
+  "migration",
+  "justice"
+]
      • addedInput schema / properties / automatedDecisions / description
        Added value: +"Does it make automated decisions with legal or similarly significant effects on people (credit, hiring, admissions…)? Adds GDPR art. 22 duties; high risk only if an Annex III domain applies."
      • addedInput schema / properties / biometricCategorisationSensitive
        Added value: +{
+  "default": false,
+  "description": "Does it use biometric data (face, voice, gait…) to infer sensitive attributes — race, political opinion, religion, trade-union membership, sexual orientation (art. 5.1.g)? Prohibited. Ordinary face-unlock or liveness checks that don't infer these attributes are NOT this.",
+  "type": "boolean"
+}
      • addedInput schema / properties / embeddedInRegulatedProduct
        Added value: +{
+  "default": false,
+  "description": "Is the AI a safety component embedded in an Annex I regulated product (toys, machinery, medical devices…)? High risk via art. 6.1, deadline Aug 2, 2028.",
+  "type": "boolean"
+}
      • addedInput schema / properties / emotionRecognitionWorkEducation
        Added value: +{
+  "default": false,
+  "description": "Does it infer emotions (frustration, attention, mood…) from employees at work or students in education, e.g. to flag disengaged staff or bored students (art. 5.1.f)? Prohibited. Emotion inference on end users of a public consumer product (not their employees/students) is NOT this.",
+  "type": "boolean"
+}
      • addedInput schema / properties / generatesContent / description
        Added value: +"Does it generate text, images, audio or video shown to users? Triggers the art. 50 duty to label AI-generated content."
      • addedInput schema / properties / individualPredictivePolicing
        Added value: +{
+  "default": false,
+  "description": "Predicting an individual's criminal risk based solely on profiling or personality traits (art. 5.1.d)? Prohibited.",
+  "type": "boolean"
+}
      • addedInput schema / properties / interactsWithPeople / description
        Added value: +"Do people interact directly with the AI (chatbot, voice assistant…)? Triggers the art. 50 duty to disclose they are talking to an AI."
      • addedInput schema / properties / manipulativeOrExploitative
        Added value: +{
+  "default": false,
+  "description": "Does it use subliminal techniques beyond a person's consciousness, or exploit a known vulnerability (age, disability, specific social or economic situation) to materially distort behavior and cause harm — e.g. dark patterns targeting a diagnosed gambling addiction (art. 5.1.a-b)? Prohibited. Ordinary persuasive marketing or UX nudges aimed at the general population are NOT this.",
+  "type": "boolean"
+}
      • addedInput schema / properties / realtimeBiometricLawEnforcement / description
        Added value: +"Only if realtimeBiometricPublic: is it used for LAW ENFORCEMENT purposes? That combination is prohibited (art. 5.1.h) and already in force."
      • addedInput schema / properties / realtimeBiometricPublic / description
        Added value: +"Real-time remote biometric identification in publicly accessible spaces (e.g. live face recognition)? High risk (Annex III biometrics) — prohibited only when combined with realtimeBiometricLawEnforcement."
      • addedInput schema / properties / socialScoring / description
        Added value: +"Does it score people's social behavior or traits causing detrimental treatment in unrelated contexts, or disproportionate to the behavior (art. 5.1.c)? Prohibited. A seller rating or fitness points app is NOT this."
      • addedInput schema / properties / untargetedFaceScraping
        Added value: +{
+  "default": false,
+  "description": "Does it untargetedly scrape facial images from the internet or CCTV footage to build or expand a face-recognition database (art. 5.1.e)? Prohibited. Matching a user's own consented selfie against their own ID photo is NOT this.",
+  "type": "boolean"
+}
      • addedInput schema / properties / usesAI / description
        Added value: +"Does the product use AI at all (LLM calls, recommendations, computer vision…)? false ⇒ minimal risk, the AI Act does not apply."
    • Changedcheck_website1 field changed
      • changedInput schema / properties / url / description
        Previous value: -"Public URL (or bare domain) of the deployed site, e.g. https://myapp.com"New value: +"Public URL (or bare domain) of the deployed site, e.g. https://myapp.com or myapp.com. Must be publicly reachable."
    • Changedgenerate_policies5 fields changed
      • addedInput schema / properties / appName / description
        Added value: +"App / business name shown in the documents, e.g. 'Acme Notes'."
      • addedInput schema / properties / contactEmail / description
        Added value: +"Privacy contact email published in the documents. If omitted, a [to complete] placeholder is left."
      • changedInput schema / properties / entity / description
        Previous value: -"Data controller / legal entity."New value: +"Data controller / legal entity (person or company legally responsible), e.g. 'Acme Labs S.L.'. If omitted, the documents keep a [to complete] placeholder."
      • addedInput schema / properties / locales / description
        Added value: +"Languages to generate the documents in (ISO 639-1). Defaults to the markets' main languages; anonymous calls are capped at 3 locales. Pass scan_project's `locales` to match the languages the app actually ships."
      • addedInput schema / properties / markets / description
        Added value: +"Regions where the app has users (at least one). Each market pack cites its frameworks: eu → GDPR/ePrivacy, uk → UK GDPR/PECR, us → CCPA/CPRA, ca → PIPEDA, latam → LGPD…; 'global' covers all of them at the highest common bar."
    • Changedget_claim_status1 field changed
      • changedInput schema / properties / code / description
        Previous value: -"The claim code returned by claim_app."New value: +"The claim code returned by claim_app (not the URL — the `code` field)."
    • Changedinstall_snippet3 fields changed
      • addedInput schema / properties / accent / description
        Added value: +"Banner accent color as a CSS hex value, e.g. #4f46e5. Defaults to the color detected from the app's own styles (see `theme`)."
      • changedInput schema / properties / appId / description
        Previous value: -"App id (defaults to LEXVIBE_APP_ID)."New value: +"LexVibe app id, e.g. from claim_app/get_claim_status (defaults to the LEXVIBE_APP_ID env var; without either, the YOUR_APP_ID placeholder is used and flagged)."
      • changedInput schema / properties / file / description
        Previous value: -"File to install into (index.html, app/layout.tsx…)."New value: +"Path of the file to install into (index.html, app/layout.tsx…)."
    • Changedmake_compliant3 fields changed
      • addedInput schema / properties / accent / description
        Added value: +"Banner accent color as a CSS hex value, e.g. #4f46e5. Defaults to the LexVibe accent."
      • changedInput schema / properties / appId / description
        Previous value: -"LexVibe app id (defaults to LEXVIBE_APP_ID)."New value: +"LexVibe app id (defaults to the LEXVIBE_APP_ID env var). Without a real id the snippet uses the YOUR_APP_ID placeholder and the result tells you to call claim_app."
      • addedInput schema / properties / markets / description
        Added value: +"Regions where the app has users; they decide which frameworks the documents cover (eu → GDPR, uk → UK GDPR, us → CCPA/CPRA…). Defaults to [\"eu\"] — confirm with the user before accepting that default."
    • Changedscan_project1 field changed
      • changedInput schema / properties / dir / description
        Previous value: -"Path to the project to analyze (repo root)."New value: +"Path of the project root to analyze (absolute paths are safest)."
  4. 10 tool updatesv0.1.9
    • First observedcheck_ai_act
    • First observedcheck_compliance
    • First observedcheck_website
    • First observedclaim_app
    • First observedgenerate_policies
    • First observedget_claim_status
    • First observedinstall_snippet
    • First observedmake_compliant
    • First observedscan_project
    • First observedverify_snippet
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0
Disambiguation4/5

Most tools have distinct purposes, but there is potential confusion between generate_policies and make_compliant (both generate documents) and between scan_project and check_compliance (both scan projects). However, detailed descriptions help differentiate them, and the overlap is intentional for different use cases.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, e.g., check_compliance, install_snippet, get_claim_status. The naming is predictable and clear, making it easy for an agent to infer functionality.

Tool Count5/5

With 10 tools, the set covers the legal compliance workflow comprehensively without bloat. Each tool serves a clear role, from scanning to generation to installation and verification, and the count feels appropriate for the domain.

Completeness4/5

The tool set covers the full lifecycle: scanning (scan_project, check_website), compliance checking (check_compliance, check_ai_act), policy generation, snippet installation, verification, and account linking. Minor gaps like no explicit tool for updating existing policies are mitigated by make_compliant which regenerates them.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/marcosnovo/lexvibe-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server