Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DarkLens MCP Server audit example.com for dark patterns"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A production-grade Model Context Protocol (MCP) server that enables AI agents to detect, classify, explain, and ethically redesign dark patterns in websites and UI flows.
DarkLens analyzes UI elements, consent flows, pricing structures, and interaction friction to identify manipulative design patterns. It provides structured JSON outputs suitable for reasoning and compliance assessment.
Related MCP server: atlas-browser-mcp
Pattern Detection: Rule-based + NLP heuristics for identifying 9+ dark pattern categories
Classification: Categorizes patterns with cognitive bias analysis and severity levels
Ethical Explanations: Plain-English explanations of manipulation tactics and harm potential
Compliance Assessment: Risk scoring under GDPR, FTC, and DPDP regulations
Ethical Alternatives: Suggests redesigned UI flows and copy
Confirmshaming
Forced Consent
Roach Motel
Hidden Costs
Sneak Into Basket
Fake Urgency
Visual Manipulation
Default Bias Exploitation
Nagging / Repeated Interruptions
Social Proof Manipulation (Enhanced with Kaggle dataset)
The detection system is enhanced with real-world examples from the Kaggle Dark Patterns Dataset, providing 2,000+ labeled examples of dark patterns across e-commerce and web interfaces.
Python 3.10 or higher
uv package manager (recommended) or pip
# Install uv if you haven't already
curl -LsSf https://astral.sh/uv/install.sh | sh
# Clone or navigate to the project directory
cd /path/to/DarkLens-MCP-Server
# Install dependencies
uv sync# Install dependencies
pip install -e .DarkLens-MCP-Server/
├── darklens_mcp_server/
│ └── server.py # Main MCP server implementation
├── data/
│ └── dark_patterns.json # Pattern taxonomy database
├── demo/ # Example usage scripts
├── pyproject.toml # Project configuration
├── requirements.txt # Alternative dependencies
├── README.md # This file
└── uv.lock # Lock file for uvdark_patterns://taxonomy: Complete dark patterns taxonomy
ui_text://{url}: Extracted UI text elements from webpages
detect_dark_patterns: Analyze HTML/text/URL for dark patterns
classify_pattern: Get detailed classification of a pattern
explain_manipulation: Explain psychological manipulation
risk_score: Assess legal/compliance risk
suggest_ethical_alternative: Get ethical redesign suggestions
audit_website: Comprehensive website audit template
explain_ui_to_user: UI explanation for non-technical users
compliance_report: UX ethics compliance report template
rewrite_cta: Ethical CTA rewrite template
assess_gdpr_risk: GDPR risk assessment template
# With uv
uv run darklens_mcp_server
# With Python
python -m darklens_mcp_server.serverThe server communicates via stdio for MCP protocol.
Connect using any MCP-compatible client.
{
"method": "tools/call",
"params": {
"name": "detect_dark_patterns",
"arguments": {
"input_type": "url",
"content": "https://example.com"
}
}
}{
"result": [
{
"pattern_id": "confirmshaming",
"pattern_type": "Confirmshaming",
"confidence": 0.9,
"evidence": ["No thanks, I don't want to save money"]
}
]
}Input:
input_type: "html" | "text" | "url"
content: String content to analyze
Output: Array of detected patterns with ID, type, confidence, and evidence.
Input: pattern_id: String
Output: Category, cognitive bias, severity level.
Input: pattern_id: String, user_type: "child" | "elderly" | "average user"
Output: Plain explanation, psychological principle, harm potential.
Input: pattern_id: String, region: "EU" | "US" | "India"
Output: Risk score (0-100), violated regulations, enforcement likelihood.
Input: pattern_id: String
Output: Rewritten UI copy, redesigned flow, ethical justification.
This tool is designed to promote ethical UX design and regulatory compliance. Use responsibly to:
Audit websites for manipulative patterns
Educate designers on ethical alternatives
Ensure compliance with privacy and consumer protection laws
Improve user trust and experience
Disclaimer: This tool provides analysis based on established dark pattern research but should not be considered legal advice. Always consult with legal experts for compliance matters.
Contributions welcome! Please ensure code follows the established patterns and includes appropriate tests.
Resources provide read-only access to data. They are like GET endpoints in REST APIs.
@mcp.resource("users://list")
def get_users_list() -> str:
"""Get a list of all users."""
return json.dumps(SAMPLE_USERS, indent=2)@mcp.resource("users://{user_id}")
def get_user_by_id(user_id: str) -> str:
"""Get a specific user by ID."""
# Implementation...@mcp.resource("api://external/{endpoint}")
async def get_external_api_data(endpoint: str) -> str:
"""Fetch data from an external API endpoint."""
# Implementation...Tools are executable functions that can perform computations, API calls, or other actions. They may require user approval before execution.
@mcp.tool()
def calculate_sum(numbers: List[float]) -> float:
"""Calculate the sum of a list of numbers."""
return sum(numbers)@mcp.tool()
async def fetch_user_posts(user_id: int) -> str:
"""Fetch posts for a specific user from external API."""
async with httpx.AsyncClient() as client:
response = await client.get(f"{API_BASE_URL}/posts?userId={user_id}")
return json.dumps(response.json(), indent=2)@mcp.tool()
def analyze_text(text: str) -> Dict[str, Any]:
"""Analyze text and return statistics."""
words = text.split()
return {
"word_count": len(words),
"character_count": len(text),
# ... more analysis
}Prompts are reusable templates that help LLMs interact effectively with your server. They define expected inputs and interaction patterns.
@mcp.prompt()
def summarize_content(content: str, max_length: int = 100) -> str:
"""Create a prompt to summarize content."""
return f"Please summarize the following content in {max_length} words or less:\n\n{content}"@mcp.prompt()
def create_study_plan(subject: str, hours_per_week: int, weeks: int) -> str:
"""Create a study plan prompt."""
return f"""Create a detailed study plan for learning {subject}.
Available time: {hours_per_week} hours per week
Duration: {weeks} weeks
Please include:
1. Weekly breakdown of topics
2. Daily study schedule
3. Recommended resources
4. Assessment milestones
5. Tips for effective learning"""uv run darklens-serverpython -m darklens_mcp_server.serverdarklens-serverThe server will start and listen for MCP protocol messages over stdio.
The easiest way to test your MCP server is using the MCP Inspector:
# Install MCP Inspector globally
npm install -g @modelcontextprotocol/inspector
# Run the inspector with your server
mcp-inspector uv run darklens-serverThis will open a web interface where you can interact with your server's resources, tools, and prompts.
You can also create a simple test client:
import asyncio
from mcp.client.session import ClientSession
from mcp.client.stdio import StdioServerParameters, stdio_client
async def test_server():
async with stdio_client(
StdioServerParameters(command="uv", args=["run", "darklens-server"])
) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
# List resources
resources = await session.list_resources()
print("Available resources:", [r.uri for r in resources.resources])
# List tools
tools = await session.list_tools()
print("Available tools:", [t.name for t in tools.tools])
# List prompts
prompts = await session.list_prompts()
print("Available prompts:", [p.name for p in prompts.prompts])
# Test a resource
resource_content = await session.read_resource("users://list")
print("Users resource content:", resource_content.contents[0].text)
# Test a tool
result = await session.call_tool("calculate_sum", {"numbers": [1, 2, 3, 4, 5]})
print("Sum tool result:", result.content[0].text)
# Test a prompt
prompt_result = await session.get_prompt("summarize_content", {
"content": "This is a sample text to summarize.",
"max_length": 50
})
print("Prompt result:", prompt_result.messages[0].content)
asyncio.run(test_server())To use this server with Claude Desktop:
Configure Claude Desktop:
Open ~/Library/Application Support/Claude/claude_desktop_config.json
Add your server configuration:
{
"mcpServers": {
"darklens": {
"command": "uv",
"args": [
"--directory",
"/path/to/DarkLens-MCP-Server",
"run",
"darklens-server"
]
}
}
}Restart Claude Desktop
Test in Claude:
Ask Claude to "list available resources" or "use the calculate_sum tool"
Try prompts like "create a study plan for learning Python with 10 hours per week for 8 weeks"
users://list - List all sample users
users://{user_id} - Get specific user by ID
posts://list - List all sample posts
api://external/{endpoint} - Fetch data from JSONPlaceholder API
calculate_sum - Sum a list of numbers
find_max - Find maximum value in a list
reverse_string - Reverse a string
fetch_user_posts - Fetch posts for a user from external API
analyze_text - Analyze text statistics
summarize_content - Create a summarization prompt
analyze_sentiment - Create a sentiment analysis prompt
generate_code - Create a code generation prompt
create_study_plan - Create a study plan prompt
Keep resource functions lightweight - avoid heavy computation
Use appropriate MIME types for different content types
Handle errors gracefully and return meaningful error messages
Use URI templates for dynamic resources
Include clear docstrings with parameter descriptions
Validate input parameters
Handle errors appropriately
Use async functions for I/O operations
Keep tool names descriptive and consistent
Make prompts flexible with optional parameters
Include clear instructions for the LLM
Structure prompts for consistent output
Use descriptive names and descriptions
Use logging instead of print statements (MCP uses stdio for communication)
Test your server thoroughly before deployment
Handle edge cases and invalid inputs
Follow Python type hints for better tooling support
Check Python version (must be 3.10+)
Verify all dependencies are installed
Check for syntax errors in your code
Ensure decorators are applied correctly (@mcp.tool(), not @mcp.tool)
Check that functions have proper type hints
Verify server initialization
Check the path to your server in the config file
Ensure the server starts without errors
Restart Claude Desktop after config changes
Check Claude Desktop logs for errors
"print() breaks MCP": Never use print() in production - it corrupts the JSON-RPC protocol
"Async function required": Use async def for functions that perform I/O
"Invalid URI": Ensure resource URIs follow proper format
Explore the MCP documentation for advanced features
Check out the Python SDK examples
Learn about building MCP clients
Discover other MCP servers
This project is provided as an educational example. Feel free to modify and extend it for your own MCP server implementations.
Analyze text and return statistics.
Args: text: The text to analyze
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says the tool returns statistics, without stating whether the operation is read-only, what happens to the input, whether there are length limits, or what specific statistics are computed. This is too thin for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and contains no filler. The Args block adds a small amount of useful parameter context, but the opening phrase partially restates the tool name, so it does not earn a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description is minimally adequate: it names the input and the broad output type. However, 'statistics' is vague and there is no guidance relative to the sibling tools, so an agent still lacks confidence about what the tool will compute and when to prefer it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly defines the single parameter, text, as 'The text to analyze.' This adds a semantic role beyond the schema's bare string type, though it is minimal and does not mention format, length, or other constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb ('Analyze') and a resource ('text') and states that it returns statistics, but 'statistics' is left unspecified. It does not distinguish this generic utility from sibling tools like detect_dark_patterns or classify_pattern, so an agent cannot tell exactly what kind of analysis is being offered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling text-analysis tools. Since the sibling list contains tools with more specific purposes, an agent would have to guess whether analyze_text is the general-purpose option or if it is only for certain kinds of text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify a detected dark pattern.
Args: pattern_id: The ID of the pattern to classify
Returns: Dictionary with category, cognitive_bias, severity
| Name | Required | Description | Default |
|---|---|---|---|
| pattern_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It states the return dictionary and implies a non-mutating analysis operation, but it does not disclose error behavior, whether the pattern_id must exist, or any permissions/side-effect information. This is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a one-sentence purpose, a single Args entry, and a Returns line. Every sentence contributes information and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the basics and is enough to invoke if an agent already has a pattern_id. However, with no annotations and a sibling group containing similar dark-pattern tools, it would benefit from an explicit prerequisite or a pointer to detect_dark_patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args line is the only explanation of pattern_id. It adds that the ID belongs to the pattern being classified, which is slightly more than the schema title 'Pattern Id', but it does not explain where the ID comes from or any format expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line 'Classify a detected dark pattern' names a specific verb and resource, and the Returns line ('category, cognitive_bias, severity') clarifies exactly what classification produces. This distinguishes it from sibling tools like detect_dark_patterns, explain_manipulation, and risk_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'detected' implies the tool operates on an existing pattern, suggesting it should be used after detection, but the description never explicitly says when to prefer classify_pattern over siblings such as explain_manipulation or risk_score. No exclusions or alternative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect dark patterns in UI text, HTML, or URL.
Args: input_type: "html", "text", or "url" content: The HTML content, plain text, or URL to analyze
Returns: List of detected patterns with pattern_id, pattern_type, confidence, evidence
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| input_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the behavioral disclosure burden. It does reveal the return shape (list with pattern_id, pattern_type, confidence, evidence), which is useful, but it does not disclose error behavior, input constraints, or whether the operation is read-only in any explicit way.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses a compact Args/Returns structure. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter detection tool, the description covers the purpose, both parameters, and the return format. An output schema exists, reducing the need to explain return values further. It could be more complete by addressing how invalid input_type values are handled or how to choose between this and sibling tools, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining both parameters: input_type values ('html', 'text', or 'url') and what content contains. This adds meaning well beyond the bare schema, which only names the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects dark patterns in UI text, HTML, or URL, specifying a concrete verb and resource. It is understandable, though it does not explicitly differentiate itself from related siblings like classify_pattern or analyze_text beyond its dark-pattern focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear sense of what input types are accepted, but it provides no guidance on when to use this tool versus alternatives such as classify_pattern or analyze_text. There are no exclusions, prerequisites, or explicit usage conditions beyond the basic input_type/content split.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain why a pattern is manipulative.
Args: pattern_id: The ID of the pattern user_type: Type of user (child, elderly, average user)
Returns: Dictionary with explanation, psychological principle, harm potential
| Name | Required | Description | Default |
|---|---|---|---|
| user_type | No | average user | |
| pattern_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The verb 'explain' and the Returns line imply a read-only operation, but the description does not address failure behavior, whether user_type changes the result, or any permissions or errors. This is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, an Args block, and a Returns block. Every line adds necessary information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, but the description leaves some operational context unstated: where pattern_id comes from, whether user_type is optional, and how the explanation varies by user type. Given the sibling tools, a pointer to detect_dark_patterns as the source of pattern_id would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does describe both parameters and gives example user_type values (child, elderly, average user), but pattern_id is only restated as 'The ID of the pattern' and the effect of user_type on the explanation is left implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Explain why a pattern is manipulative' states a specific verb, object, and intent, and the Returns line clarifies that this is about reasoning and harm potential. It is clearly distinguishable from detect/classify/scoring siblings, though it does not explicitly name them or state what the tool is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over detect_dark_patterns, classify_pattern, or risk_score. The description does not mention prerequisites, sequencing, or whether this tool should be used after detection or classification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch posts for a specific user from external API.
Args: user_id: The user ID to fetch posts for
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'Fetch' implies a read-only operation and 'from external API' signals potential network dependency, but auth requirements, rate limits, error behavior, or pagination are not disclosed. It provides some context but not comprehensive behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loads the main purpose. The Args block is somewhat redundant with the schema but is clearly structured and does not add significant verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter fetch tool with an output schema, the description is adequate but not thorough. It omits external API specifics such as authentication, rate limits, pagination, or failure modes, though these may be less critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must compensate. It explains user_id as 'The user ID to fetch posts for', which adds basic role semantics beyond the schema's type and title. However, this is minimal and largely inferable from the tool name, and it does not add constraints or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Fetch'), a clear resource ('posts'), and a scope ('for a specific user from external API'). This distinguishes it from sibling tools like detect_dark_patterns and classify_pattern, which are clearly analysis/classification operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any of the sibling tools or conditions under which this tool is preferred, leaving the agent to infer from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess legal/compliance risk of a pattern.
Args: pattern_id: The ID of the pattern region: Geographic region (EU, US, India)
Returns: Dictionary with risk score, violated regulations, enforcement likelihood
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | ||
| pattern_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It conveys a read-only assessment operation and lists the return content, but it does not explicitly state side effects, data-source assumptions, or behavior for invalid regions or pattern IDs. That leaves some ambiguity, though nothing contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and organized into Args and Returns sections. Every sentence adds information; there is no filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description is nearly complete: it defines the operation, both parameters, and the return shape. The main gap is the lack of usage guidance relative to sibling tools, but that is already penalized in its own dimension. Nothing essential for calling the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining pattern_id as 'The ID of the pattern' and by listing the expected region values (EU, US, India), which the schema itself does not provide. The pattern_id explanation is thin, but the region guidance is genuinely useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object — 'Assess legal/compliance risk of a pattern' — which states exactly what the tool computes. The legal/compliance angle separates it from sibling tools like classify_pattern or detect_dark_patterns, so an agent can distinguish it without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose risk_score over siblings such as classify_pattern or explain_manipulation, and no exclusions or prerequisites are mentioned. The purpose statement implies a use case, but the description never tells the agent how to route to this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest ethical UI alternatives.
Args: pattern_id: The ID of the pattern
Returns: Dictionary with rewritten UI copy, redesigned flow, ethical justification
| Name | Required | Description | Default |
|---|---|---|---|
| pattern_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral transparency burden. It discloses a dictionary return value with rewritten copy, redesigned flow, and ethical justification, but it does not state whether the tool has side effects, requires dependencies or permissions, or what happens on missing or invalid pattern IDs. The verb 'suggest' implies non-mutating behavior, but that is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the main purpose, and uses a clear Args/Returns structure. It avoids filler and each section adds some value, though the parameter description is thin.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool embedded among dark-pattern analysis tools. It does not explain how to obtain pattern_id, when this tool should be called in a workflow, or how the returned alternatives relate to outputs from sibling tools. The output schema may cover return structure, but the surrounding context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, pattern_id, and the description adds only 'The ID of the pattern,' which essentially restates the schema title 'Pattern Id.' Schema description coverage is 0%, so the description needed to compensate by explaining where the ID comes from, its format, or its relationship to other tools, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and object: 'Suggest ethical UI alternatives.' The Args/Returns section makes clear it operates on a pattern and returns alternative UI copy, flow, and justification. It does not explicitly distinguish it from siblings like detect_dark_patterns or classify_pattern, but its purpose is reasonably self-evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus detect_dark_patterns, classify_pattern, explain_manipulation, or risk_score. The only implicit cue is the phrase 'ethical UI alternatives,' which is not enough to route an agent to this tool among related siblings. No exclusions or alternative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0analyze_textclassify_patterndetect_dark_patternsexplain_manipulationfetch_user_postsrisk_scoresuggest_ethical_alternativeThe first five tools form a clear detection-to-remediation pipeline, each consuming a pattern_id and returning a distinct analysis. However, analyze_text overlaps somewhat with detect_dark_patterns for text input, and fetch_user_posts is unrelated, creating minor confusion.
Most tools follow a clean snake_case verb_noun pattern such as detect_dark_patterns and suggest_ethical_alternative. risk_score breaks the pattern since it reads as a noun rather than a verb, but the style is otherwise consistent.
Seven tools is a reasonable number and the core dark-pattern workflows are wel-scoped. The presence of two unrelated utility tools means not every tool earns its pplace, but the count is not excessive.
The dark-pattern domain is covered end-to-end: detect, classify, explain, assess risk, and suggest alternatives. The unrelated fetch_user_posts and analyze_text tools do not address domain gaps, but no critical dark-pattern operation is missing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
Scores any public website on how usable it is by AI agents, with per-check evidence.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Manavarya09/DarkLens-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
