Supports configuration on macOS through a specific configuration file path for Claude Desktop integration.
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., "@Consumer Rights Wiki MCP Server search for dark patterns in mobile apps"
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 Model Context Protocol (MCP) server that provides access to the Consumer Rights Wiki, a platform documenting modern consumer exploitation issues.
This MCP server enables AI assistants to interact with the Consumer Rights Wiki (https://consumerrights.wiki), which documents various forms of consumer exploitation including:
Privacy violations and data misuse
Dark patterns in user interfaces
Forced arbitration clauses
Ownership rights violations
Deceptive pricing practices
And more modern consumer issues
Related MCP server: public-ai-mcp-server
The server provides the following tools:
search_wikiSearch for articles in the Consumer Rights Wiki.
Parameters:
query (required): Search terms
limit (optional): Number of results (default: 10, max: 50)
get_page_contentRetrieve the full content of a specific wiki page.
Parameters:
title (required): The page title
section (optional): Specific section number to retrieve
get_page_infoGet metadata about a wiki page including revision history, categories, and protection status.
Parameters:
title (required): The page title
get_recent_changesView recent changes to the wiki.
Parameters:
limit (optional): Number of changes to return (default: 10, max: 50)
namespace (optional): Filter by namespace (0 = main articles)
get_categoriesList all categories or pages within a specific category.
Parameters:
category (optional): Category name (without "Category:" prefix)
limit (optional): Number of results (default: 20, max: 50)
get_page_sectionsGet the section structure of a wiki page.
Parameters:
title (required): The page title
Clone this repository or create a new directory:
mkdir consumer-rights-wiki-mcp
cd consumer-rights-wiki-mcpSave the provided files:
src/index.ts (the main server code)
package.json
tsconfig.json
Install dependencies:
npm installBuild the TypeScript code:
npm run buildAdd the following to your Claude Desktop configuration file:
On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"consumer-rights-wiki": {
"command": "node",
"args": ["path/to/consumer-rights-wiki-mcp/build/index.js"]
}
}
}The server runs on stdio transport. Start it with:
npm startOnce configured, you can ask your AI assistant to:
Search for companies: "Search the Consumer Rights Wiki for information about X Corp"
Get detailed article content: "Get the full content of the X Corp article from Consumer Rights Wiki"
Browse recent changes: "Show me the most recent changes to Consumer Rights Wiki"
Explore categories: "What categories are available in Consumer Rights Wiki?" "Show me all articles in the 'Privacy violations' category"
Get page structure: "What sections are in the 'Apple Inc.' article?"
For development with hot reloading:
npm run devTo clean build artifacts:
npm run cleanThe server uses the public MediaWiki API, which has rate limits
Search results are limited to 50 per query
Some content may require authentication for editing (not implemented in this version)
This MCP server is designed to help expose consumer exploitation practices. Consider contributing to:
The Consumer Rights Wiki itself by documenting consumer issues
This MCP server by adding new features or improving existing ones
MIT License
Get all categories or pages in a specific category
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category name (without Category: prefix). If empty, lists all categories. | |
| limit | No | Number of results to return (default: 20, max: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool's function but lacks details on permissions, rate limits, pagination, or response format. For a read operation with no annotation coverage, this is a significant gap in transparency.
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 single, efficient sentence that clearly states the tool's purpose without redundancy. It's appropriately sized and front-loaded, with no wasted words, making it easy to parse quickly.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain return values, error handling, or behavioral constraints like rate limits. For a tool with two parameters and no structured output information, more context is needed to ensure reliable agent usage.
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 100%, so the schema already documents both parameters thoroughly. The description implies the 'category' parameter's dual role (empty for all categories, specified for pages in that category), but doesn't add syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema handles most parameter documentation.
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's purpose with specific verbs ('Get all categories' or 'pages in a specific category') and identifies the resource (categories/pages). It distinguishes between two modes (list all categories vs. list pages in a category), but doesn't explicitly differentiate from siblings like 'get_page_content' or 'search_wiki' beyond the resource 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_page_info' or 'search_wiki', nor does it specify contexts where this tool is preferred or excluded, leaving usage decisions ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full content of a specific wiki page
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | The title of the wiki page | |
| section | No | Optional section number to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions retrieving 'full content' but doesn't specify format (e.g., HTML, plain text), pagination, error handling, or authentication requirements. This leaves significant gaps for a read operation tool.
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 single, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple retrieval tool, making it easy to parse quickly.
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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'full content' includes (e.g., text, images, metadata), return format, or error scenarios. Given the complexity of wiki content retrieval and lack of structured data, more context is needed.
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 100%, so the schema already documents both parameters (title and optional section). The description adds no additional parameter semantics beyond implying retrieval of content, which aligns with the schema but doesn't provide extra value like format details or examples.
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 action ('Get the full content') and resource ('a specific wiki page'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like get_page_info or get_page_sections, which also retrieve page-related information but with different scopes.
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 alternatives like get_page_info (which might return metadata) or get_page_sections (which might list sections). It simply states what the tool does without context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata about a wiki page
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | The title of the wiki page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states 'Get metadata' which implies a read-only operation, but doesn't specify what metadata includes (e.g., last modified, author, page size), whether it requires authentication, or if there are rate limits. This leaves significant gaps in understanding the tool's behavior.
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 single, clear sentence with no wasted words. It's appropriately sized for a simple tool and front-loads the essential information ('Get metadata about a wiki page'), making it easy to parse quickly.
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 read tool with one parameter and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on what metadata is returned, how to handle errors, or when to choose this over siblings. Without annotations or output schema, more context would be helpful for the agent to use it effectively.
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 description adds no parameter information beyond what's in the schema, which has 100% coverage for the single 'title' parameter. Since schema coverage is high, the baseline is 3, but the description doesn't provide additional context like format examples or edge cases for the title parameter.
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 'Get metadata about a wiki page' clearly states the action (get) and resource (wiki page metadata), making the purpose immediately understandable. However, it doesn't differentiate from siblings like 'get_page_content' or 'get_page_sections' which also retrieve page information but of different types, so it lacks specific sibling distinction.
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 alternatives. With siblings like 'get_page_content' (for full content) and 'get_page_sections' (for structural breakdown), there's no indication that this tool is specifically for metadata rather than other page aspects, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the section structure of a wiki page
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | The title of the wiki page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' data, implying a read-only operation, but doesn't specify permissions, rate limits, error handling, or what the output looks like (e.g., format of section structure). This leaves significant gaps for a tool with no structured safety hints.
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 single, clear sentence with zero wasted words. It's front-loaded with the core purpose, making it efficient and easy to parse, which is ideal for conciseness.
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?
Given no annotations, no output schema, and a simple parameter schema, the description is incomplete. It doesn't explain what 'section structure' entails (e.g., hierarchical data, metadata), potential errors, or usage context, which is inadequate for a tool that might return complex data without structured output documentation.
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 input schema has 100% description coverage, with the single parameter 'title' documented as 'The title of the wiki page'. The description adds no additional meaning beyond this, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating value.
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 action ('Get') and resource ('section structure of a wiki page'), making the purpose understandable. However, it doesn't differentiate from siblings like 'get_page_content' or 'get_page_info' which might also retrieve page-related data, so it's not fully specific about what distinguishes this tool.
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 alternatives like 'get_page_content' or 'get_page_info'. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent changes to the wiki
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recent changes to return (default: 10, max: 50) | |
| namespace | No | Filter by namespace (0 = main articles) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but lacks details on permissions, rate limits, output format, pagination, or whether changes are filtered by type (e.g., edits, deletions). For a read operation with zero annotation coverage, this is a significant gap.
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 single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'recent changes' entails (e.g., edit history, timestamps, user info) or the return format, leaving gaps in understanding the tool's behavior and output.
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 input schema has 100% description coverage, with clear documentation for both parameters (limit and namespace), including defaults and examples. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
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 verb ('Get') and resource ('recent changes to the wiki'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools like 'get_page_info' or 'search_wiki' that might also retrieve wiki-related information, preventing a perfect 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 description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_page_info' and 'search_wiki' available, there's no indication of whether this tool is for chronological updates, specific content types, or other contexts, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for articles in the Consumer Rights Wiki
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| limit | No | Number of results to return (default: 10, max: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions searching but doesn't describe how results are returned (e.g., relevance ranking, pagination), what fields are included in results, error conditions, or performance characteristics. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose and avoids redundancy, making it easy to parse quickly. Every part of the sentence contributes essential information.
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?
Given the lack of annotations and output schema, the description is insufficient for a search tool. It doesn't explain what the search returns (e.g., article titles, snippets, metadata), how results are structured, or any limitations like timeouts or result quality. For a tool with 2 parameters and no structured output documentation, more context is needed to use it effectively.
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 100%, with both parameters ('query' and 'limit') well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what the schema provides, such as search syntax examples or result format details. This meets the baseline for high schema coverage but doesn't enhance understanding.
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 action ('Search for articles') and resource ('Consumer Rights Wiki'), making the purpose immediately understandable. However, it doesn't differentiate this search tool from potential sibling tools like 'get_recent_changes' or 'get_categories' that might also retrieve wiki content, so it doesn't reach the highest 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 description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_page_content' and 'get_page_info' available, there's no indication whether this is for general discovery, specific lookups, or how it differs from other retrieval methods. It merely states what it does, not when to choose it.
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.
get_categoriesget_page_contentget_page_infoget_page_sectionsget_recent_changessearch_wikiScored across 6 tools
Every tool has a clearly distinct purpose with no ambiguity: get_categories handles category listings, get_page_content retrieves full page text, get_page_info provides metadata, get_page_sections gives structural details, get_recent_changes shows edit history, and search_wiki performs article searches. The descriptions clearly differentiate each tool's function, making misselection unlikely.
All tool names follow a consistent verb_noun pattern with 'get_' or 'search_' prefixes, using snake_case uniformly throughout. This predictable naming scheme (e.g., get_page_content, search_wiki) makes the tool set easily navigable and understandable at a glance.
With 6 tools, this server is well-scoped for a wiki interface, covering essential operations like content retrieval, metadata access, structure analysis, change tracking, and search. Each tool earns its place without redundancy, avoiding both excessive complexity and insufficient functionality.
The tool set provides comprehensive read-only coverage for a wiki domain, including content, metadata, structure, history, and search. A minor gap exists in write operations (e.g., edit_page or create_page), but agents can still perform most common wiki interactions effectively with the available tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered product search, affiliate links, and price negotiation for e-commerce platforms
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Real-time Amazon, WIPO & PACER data for AI agents — 19 tools via the MCP protocol.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cicatriiz/consumer-rights-wiki-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
