Skip to main content
Glama
marcosnovo

@lexvibe/mcp

by marcosnovo
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

claim_app

Create a LexVibe app in your account by providing a URL or app name. Generates a claim link that expires in 30 minutes, which the user must confirm to link policies and compliance documents.

Instructions

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.

Input Schema

TableJSON 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.

Tool Definition Quality

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.

Install Server

Other Tools

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