Skip to main content
Glama
bhanu403

DarkLens Compliance & Dark Pattern Auditor

by bhanu403
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

DarkLens MCP Server 🤖🔍

Real-time deceptive design and dark pattern compliance auditor for AI coding agents.

npm version License: MIT

DarkLens MCP connects Cursor, Windsurf, Claude Desktop, Antigravity, Lovable, v0, and Cline directly to the DarkLens compliance auditing engine. Your AI coding agent can automatically audit staging URLs, check newly generated JSX/HTML components for deceptive patterns (GDPR, FTC Act Sec. 5, CCPA, EU DSA), and fix non-compliant UI before code is committed.

⚡ Quickstart Configuration by Coding Agent

1. 🖱️ Cursor

  1. Go to Cursor Settings (Ctrl + , or Cmd + ,) → Features → MCP.

  2. Click + Add New MCP Server.

  3. Fill in:

    • Name: darklens

    • Type: command

    • Command: npx -y darklens-mcp

    • Environment Variables: DARKLENS_API_KEY=dl_live_YOUR_KEY

  4. In Cursor Chat or Composer, prompt:

    "@darklens audit my checkout page and fix any illegal dark patterns."

2. 🌊 Windsurf (Codeium)

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "darklens": {
      "command": "npx",
      "args": ["-y", "darklens-mcp"],
      "env": {
        "DARKLENS_API_KEY": "dl_live_YOUR_KEY"
      }
    }
  }
}

3. 🧠 Claude Desktop / Claude Code (Anthropic)

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "darklens": {
      "command": "npx",
      "args": ["-y", "darklens-mcp"],
      "env": {
        "DARKLENS_API_KEY": "dl_live_YOUR_KEY"
      }
    }
  }
}

4. 🚀 Antigravity (Google / DeepMind)

Add to your Antigravity MCP settings or call via native MCP config:

{
  "mcpServers": {
    "darklens": {
      "command": "npx",
      "args": ["-y", "darklens-mcp"],
      "env": {
        "DARKLENS_API_KEY": "dl_live_YOUR_KEY"
      }
    }
  }
}

5. ❤️ Lovable & v0 / Bolt.new

In Lovable, Bolt.new, or v0 terminal or agent custom tool integrations, execute:

npx -y darklens-mcp --key dl_live_YOUR_KEY

Or instruct the agent to run DarkLens CLI on preview URLs:

npx darklens <your-preview-url> --key $DARKLENS_API_KEY

6. đź’» VS Code (Cline / Roo Code)

  1. Open the Cline / Roo Code sidebar tab.

  2. Click the MCP icon → Configure MCP Servers.

  3. Add:

{
  "mcpServers": {
    "darklens": {
      "command": "npx",
      "args": ["-y", "darklens-mcp"],
      "env": {
        "DARKLENS_API_KEY": "dl_live_YOUR_KEY"
      }
    }
  }
}

Related MCP server: air-blackbox-mcp

🛠️ Exposed MCP Tools

Tool

Description

darklens_audit_url

Audits any public or staging URL. Returns compliance score (0-100), pass/fail, and full findings with legal citations.

darklens_audit_html

Audits raw HTML/JSX markup generated by the AI agent before it writes files to disk.

darklens_get_fair_pattern_guide

Returns exact compliant alternatives and regulatory articles for any pattern (e.g. forced_continuity, confirmshaming).

🔑 Authentication

Every request requires a DarkLens API key (dl_live_...). Get your key at darklens.dev/dashboard.

đź“„ License

MIT © DarkLens

Available Tools

3 tools
darklens_audit_htmlA

Audit raw HTML, JSX, or component markup for dark patterns (pre-checked auto-renewal checkboxes, confirmshaming guilt copy, fake countdown timers, hidden fees, missing reject buttons) before committing to production.

NameRequiredDescriptionDefault
urlNoOptional URL context (default: 'https://localhost:3000').https://localhost:3000
failOnNoFailure criterion. Default is 'score'.score
rawHtmlYesThe raw HTML or JSX markup to inspect for dark patterns.
thresholdNoMinimum acceptable passing compliance score (0-100). Default is 70.

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; "audit" implies a non-mutating inspection, but nothing states whether results are returned, thrown, or gate the caller, and the existence of failOn/threshold implies pass-fail behavior the description never explains. The examples of detected patterns add genuine value beyond structured fields, but the mutation/safety and failure semantics are left unstated.

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?

One sentence, front-loaded with the verb and resource, with the parenthetical examples earning their space by making the abstract term "dark patterns" concrete. The production-gating context lands last where it belongs.

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

Completeness3/5

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

There is no output schema, so the description is the only place an agent could learn what an audit returns—score, findings list, or violation details—and it says nothing about that. For a tool with fail-threshold semantics, the missing description of result shape is a real gap even though the input side is fully covered by the schema.

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 all four parameters including url, failOn, and threshold are already documented in the schema; baseline 3 applies. The description adds no meaning about what failOn modes do or how threshold interacts with scoring beyond what the schema says.

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

Purpose4/5

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

States a specific verb (audit) and target (raw HTML, JSX, or component markup), reinforced by concrete example detections like pre-checked auto-renewal and fake countdowns. The sibling darklens_audit_url is implicitly distinguished by the emphasis on raw markup, though the description never names the URL-based alternative directly.

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?

"Before committing to production" gives a clear usage window that routes an agent toward pre-commit inspection rather than live-page auditing. It stops short of explicitly naming darklens_audit_url as the alternative for deployed pages, so the routing is inferential rather than stated.

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

darklens_audit_urlA

Audit any staging or live URL for deceptive dark patterns, compliance risks (FTC, GDPR, CCPA, EU DSA), and sneaky checkout traps. Returns compliance score (0-100), pass/fail, and detailed findings with remediation fixes.

NameRequiredDescriptionDefault
urlYesThe target website or staging URL to audit (e.g. https://staging.myapp.com)
failOnNoFailure criterion: 'score' (score below threshold), 'critical' (only critical legal traps), or 'any'. Default is 'score'.score
thresholdNoMinimum acceptable passing compliance score (0-100). Default is 70.

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It usefully reveals the return shape (score 0-100, pass/fail, findings with remediation) and the compliance regimes checked, but says nothing about whether the audit is read-only, whether it performs a live network fetch (latency/failure modes if the site is unreachable or behind auth), or any rate limits.

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?

Two sentences, zero waste, with the capability stated first and the return contract second. Nothing is repeated from the schema and nothing is padded.

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 three-parameter audit tool with full schema coverage and no output schema, the description covers both what is checked and what comes back, which is enough to invoke it correctly. The remaining gap is operational context — network fetch behavior, timeouts, and whether staged/internal URLs are reachable.

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 url, failOn, and threshold are all documented in the schema itself. The description adds no meaning beyond that — notably it never explains failOn or threshold, which are the parameters that determine what the agent interprets as a failure.

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

Purpose4/5

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

States a specific verb and resource ("Audit any staging or live URL") and enumerates the scope of what is checked (dark patterns, FTC/GDPR/CCPA/EU DSA, checkout traps). It implicitly separates itself from darklens_audit_html by targeting a URL rather than markup, but never names the sibling or states the distinction explicitly.

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

Usage Guidelines3/5

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

"Any staging or live URL" gives loose context for when the tool applies, but there is no explicit when-not guidance and no routing between this and darklens_audit_html (URL vs raw HTML input). An agent must infer the choice from the parameter type alone.

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

darklens_get_fair_pattern_guideA

Retrieve regulatory compliance rules, legal citations (FTC Act Sec. 5, GDPR Art. 25, EU DSA Art. 25, CCPA), and compliant UI/UX alternatives for specific deceptive design categories.

NameRequiredDescriptionDefault
patternCategoryNoCategory to get remediation guidelines for (e.g., 'forced_continuity', 'confirmshaming', 'fake_urgency', 'hidden_fees', 'interface_interference', 'roach_motel').

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. The verb 'Retrieve' implies a read-only lookup and the description names the returned content, but it does not state authentication requirements, rate limits, error behavior, or output format.

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?

It is a single front-loaded sentence with no filler. Every clause contributes to identifying the tool’s purpose and returned content.

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 low-complexity, one-parameter lookup tool with no output schema, the description adequately states what is returned: rules, citations, and compliant alternatives. It could be stronger by noting output format or category handling, but the core context is present.

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 the parameter is already well documented with example categories. The description reinforces that the tool works for specific deceptive design categories but does not add syntax, valid values, or behavior 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 uses a specific verb, 'Retrieve', and clearly identifies the resource: regulatory compliance rules, legal citations, and compliant UI/UX alternatives for deceptive design categories. It is readily distinguishable from the audit siblings because it is a reference-guide lookup rather than an auditing operation.

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

Usage Guidelines3/5

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

The description implies usage by saying it is 'for specific deceptive design categories', which tells the agent when the tool applies. However, it does not explicitly say when to choose this over the sibling audit tools or what workflow it fits into.

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.

  1. 3 tool updatesv1.0.1
    • First observeddarklens_audit_html
    • First observeddarklens_audit_url
    • First observeddarklens_get_fair_pattern_guide
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation5/5

The three tools are cleanly separated by input type and purpose: auditing a live URL, auditing raw markup, and retrieving reference guidance. An agent can pick the right tool from the target artifact alone, with no overlap between them.

Naming Consistency5/5

All names use a uniform darklens_ prefix plus consistent verb_noun structure (audit_url, audit_html, get_fair_pattern_guide). The convention is predictable and the intent is readable from the name.

Tool Count4/5

Three tools map neatly to the domain's core actions (live audit, pre-commit audit, reference lookup), so nothing feels padded. It is slightly thin—no batch, history, or export tools—but the scope is deliberately focused rather than incomplete by accident.

Completeness4/5

The audit lifecycle is covered from both a live-URL and a pre-production markup angle, plus a knowledge lookup for remediation, which suits the stated purpose well. Minor gaps exist around saving/comparing past audits or exporting reports, but agents can work around them by re-running audits.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers