Requires Node.js runtime (version 18 or higher) to execute the MCP server
Uses npm for package management and running scripts to build, test, and start the server
Built on Puppeteer to provide browser automation capabilities for interacting with web pages, inspecting consent management platforms, and testing Autoconsent rules
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., "@Autoconsent MCP test the consent popup rule on https://example.com"
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 server that provides browser automation capabilities specifically designed for creating and testing Autoconsent rules. This server enables LLMs to interact with web pages, inspect consent management platforms (CMPs), and test Autoconsent rules in a real browser environment.
This server can access local files and local/internal IP addresses since it runs a browser on your machine. Exercise caution when using this MCP server to ensure this does not expose any sensitive data.
navigate
Navigate to any URL in the browser
Inputs:
url (string, required): URL to navigate to
screenshot
Capture screenshots of the entire page or specific elements
Inputs:
name (string, required): Name for the screenshot
width (number, optional, default: 1280): Screenshot width
height (number, optional, default: 720): Screenshot height
encoded (boolean, optional): If true, capture the screenshot as a base64-encoded data URI (as text) instead of binary image content. Default false.
click
Click elements on the page
Input: selector (string): CSS selector for element to click
select
Select an element with SELECT tag
Inputs:
selector (string): CSS selector for element to select
value (string): Value to select
evaluate
Execute JavaScript in the browser console
Input: script (string): JavaScript code to execute
search_html
Outputs the HTML of elements that deeply contain the given search query. Elements that don't contain the given query are omitted using a [...] placeholder.
Input: query (string): Search query
print_element
Outputs the full HTML of the given element
Input: selector (string): CSS selector
test_rule
Tests the given Autoconsent rule on the given URL
Inputs:
url (string, required): URL to navigate to
rule (object, required): Autoconsent rule (AutoConsentCMPRule)
The server provides access to two types of resources:
Console Logs (console://logs)
Browser console output in text format
Includes all console messages from the browser
Screenshots (screenshot://)
PNG images of captured screenshots
Accessible via the screenshot name specified during capture
Related MCP server: Puppeteer MCP Server
Node.js (version 18 or higher)
npm
npm install
npm run buildFor development:
npm run devFor production:
npm startnpm run serve-test-siteThis starts a local HTTP server on port 8080 serving the test-site directory.
npm run test:unit
npm run test:integrationNote that the integration tests require the test site to be running (see above).
Add the following to your Claude Desktop configuration:
{
"mcpServers": {
"autoconsent-mcp": {
"command": "node",
"args": ["path/to/autoconsent-mcp/dist/index.js"]
}
}
}This project is based on the Puppeteer MCP server from https://github.com/modelcontextprotocol/servers-archived/tree/main/src/puppeteer.
This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License.
Click elements on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for element to click |
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 the action ('click elements') but doesn't describe what happens after clicking (e.g., page navigation, event triggers, error handling), or any constraints like rate limits or permissions needed. 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 extremely concise with a single, direct sentence ('Click elements on the page') that front-loads the core action. There is no wasted verbiage, making it efficient and easy to parse.
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 tool's complexity (interactive action on web elements) and lack of annotations or output schema, the description is insufficient. It doesn't cover behavioral outcomes, error cases, or integration with sibling tools like 'navigate', leaving the agent with incomplete context for effective use.
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, clearly documenting the 'selector' parameter as a CSS selector. The description doesn't add any extra meaning beyond this, such as examples or constraints on selectors, so it meets the baseline for high schema coverage without compensating further.
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 ('click') and resource ('elements on the page'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential sibling interactions like 'select' or 'test_rule', which might also involve element interaction.
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 'select' or 'test_rule', nor does it mention prerequisites such as needing a page to be loaded first. It lacks explicit context or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript in the browser console
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JavaScript code to execute |
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 the action but does not cover critical aspects like permissions needed, side effects (e.g., modifying page state), error handling, or execution context (e.g., sandboxing). This is a significant gap for a tool that executes arbitrary code.
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 with zero waste. It is front-loaded and directly communicates the core functionality without unnecessary details, making it highly concise and well-structured.
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 complexity of executing JavaScript in a browser (a potentially risky operation with no annotations or output schema), the description is incomplete. It lacks information on return values, error cases, security implications, and how it integrates with sibling tools, making it inadequate for safe and effective use.
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 'script' parameter clearly documented. The description adds no additional meaning beyond the schema, such as examples or constraints on the JavaScript code. Baseline score of 3 is appropriate as the schema does the heavy lifting.
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 ('Execute JavaScript') and the context ('in the browser console'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'test_rule' or 'search_html' that might also involve JavaScript execution, so it lacks sibling differentiation.
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 does not mention scenarios like debugging, automation, or interactions with other tools such as 'click' or 'navigate', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Outputs the full HTML of the given element
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic function. It doesn't disclose whether this is a read-only operation, if it requires the element to be visible/loaded, what happens with invalid selectors, or any performance/rate limit considerations. For a tool with zero annotation coverage, this is insufficient behavioral context.
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 with zero wasted words. It's appropriately sized for a simple tool and front-loads the 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?
For a single-parameter tool with 100% schema coverage but no annotations and no output schema, the description is minimally adequate. It explains what the tool does but lacks context about when to use it, behavioral details, or what the output looks like (HTML string format, error cases). Given the simplicity, it's passable but has clear gaps.
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% (the 'selector' parameter is documented as 'CSS selector'), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides—it doesn't clarify selector syntax examples, scope, or special cases.
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 ('Outputs') and resource ('full HTML of the given element'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'search_html' or 'select', but the verb+resource combination is specific enough for basic understanding.
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 provided on when to use this tool versus alternatives like 'search_html' (which might search within HTML) or 'select' (which might interact with elements). The description only states what it does, not when it's appropriate or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload the current page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. 'Reload' implies a page refresh, but it doesn't specify whether this preserves session data, handles JavaScript execution, or has side effects like triggering page events. For a mutation tool with zero 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 with zero waste—'Reload the current page' directly conveys the core action without unnecessary elaboration. It's appropriately sized and front-loaded for a simple tool.
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 tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is minimally adequate but incomplete. It states what the tool does but fails to address behavioral aspects like side effects or usage context, which are important for a browser interaction tool. A score of 3 reflects this basic sufficiency with clear gaps.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, and it correctly implies no required inputs by not mentioning any. A baseline of 4 is appropriate for zero-parameter tools.
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 'Reload the current page' clearly states the action (reload) and target (current page) with a specific verb+resource. However, it doesn't differentiate from potential sibling tools like 'navigate' or 'reset_browser_data' that might have overlapping functionality, 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 like 'navigate' for URL changes or 'reset_browser_data' for clearing cache. It lacks explicit when/when-not instructions or named alternatives, offering only a basic action statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset browser data including cookies, cache, localStorage, and sessionStorage
| Name | Required | Description | Default |
|---|---|---|---|
| clearCookies | No | Clear browser cookies (default: true) | |
| clearCache | No | Clear browser cache (default: true) | |
| clearLocalStorage | No | Clear localStorage (default: true) | |
| clearSessionStorage | No | Clear sessionStorage (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'reset' implying a destructive mutation, but doesn't disclose behavioral traits such as whether this requires specific permissions, if changes are irreversible, potential side effects (e.g., logged-out sessions), or rate limits. For a mutation tool 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 with zero waste. It's front-loaded with the core action and includes specific examples without unnecessary elaboration. Every word earns its place, making it highly concise and well-structured.
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 tool's complexity (destructive mutation with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or provide enough context for safe and effective use. A mutation tool should include more behavioral and usage details to be complete.
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 all four parameters with clear descriptions and defaults. The description lists the data types (cookies, cache, localStorage, sessionStorage) that map to parameters, but adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
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 'reset' and the resource 'browser data', with specific examples (cookies, cache, localStorage, sessionStorage). It distinguishes from siblings like 'reload' or 'navigate' by focusing on data clearing rather than navigation or interaction. However, it doesn't explicitly differentiate from all siblings, missing 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. It doesn't mention prerequisites, consequences, or typical use cases (e.g., for testing, privacy, or troubleshooting). With siblings like 'reload' or 'click', there's no explicit comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture screenshots of the entire page or specific elements
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the screenshot | |
| width | No | Width in pixels (default: 1280) | |
| height | No | Height in pixels (default: 720) | |
| encoded | No | If true, capture the screenshot as a base64-encoded data URI (as text) instead of binary image content. Default false. |
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 mentions what the tool does but fails to describe critical traits such as whether it requires specific permissions, how it handles errors, if it modifies browser state, or what the output format looks like (e.g., file vs. data). This leaves significant gaps for a tool that interacts with browser content.
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 any redundant or unnecessary information. It's appropriately sized and front-loaded, making it easy for an agent 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 complexity of a screenshot tool (involving browser interaction and output handling), the description is incomplete. With no annotations and no output schema, it fails to address key aspects like the output format (e.g., image file, base64 string), error conditions, or dependencies on browser state, leaving the agent with insufficient context for reliable use.
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 description coverage is 100%, so the schema fully documents all four parameters. The description adds no additional meaning beyond what's in the schema, such as explaining the interaction between parameters or providing examples. This meets the baseline for high schema coverage.
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 ('capture screenshots') and specifies the scope ('entire page or specific elements'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'print_element' which might have overlapping functionality, 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 like 'print_element' or other sibling tools. It lacks context about use cases, prerequisites, or exclusions, leaving the agent with minimal direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Outputs the HTML of elements that deeply contain the given search query. Elements that don't contain the given query are omitted using a [...] placeholder.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it outputs HTML of matching elements and uses placeholders for non-matching ones. However, it lacks details on permissions, rate limits, error handling, or output format specifics, leaving gaps for a tool with no annotation coverage.
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 two sentences, front-loaded with the main purpose and followed by a clarifying detail about placeholder usage. Every sentence adds value with zero waste, making it appropriately sized and efficient.
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 single-parameter tool, the description is adequate but incomplete. It explains what the tool does but lacks details on output format (e.g., structure of returned HTML), error cases, or performance considerations, which would help an agent use it correctly.
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 the 'query' parameter fully. The description adds no additional meaning beyond what the schema provides, such as syntax examples or query format details. Baseline 3 is appropriate when schema does the heavy lifting.
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 verb ('outputs') and resource ('HTML of elements'), and distinguishes it from siblings by specifying it searches for elements containing a query and omits others with placeholders. This is more specific than generic tools like 'evaluate' or 'select'.
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 implies usage for searching HTML content with a query, but does not explicitly state when to use this tool versus alternatives like 'select' or 'evaluate'. It provides clear context (searching elements with queries) but lacks explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an element with SELECT tag
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for element to select | |
| value | Yes | Value to select |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'select an element' but doesn't disclose behavioral traits such as whether this triggers events, requires page focus, has side effects, or how it handles errors. This leaves the agent guessing about 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, efficient sentence with no wasted words. It's front-loaded with the core action, though it could be more structured by including usage hints, but it earns points for brevity.
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 tool that likely interacts with a browser or UI (inferred from siblings like 'click' and 'navigate'), the description is incomplete. It doesn't explain the return value, error conditions, or dependencies, leaving significant gaps for the agent.
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 ('selector' and 'value') fully. The description adds no additional meaning beyond what the schema provides, such as examples or context for the parameters, but the baseline is 3 when schema coverage is high.
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 the action ('select') and target ('element with SELECT tag'), but it's vague about what 'select' means in this context. It doesn't specify whether this is for UI automation, form filling, or DOM manipulation, and it doesn't distinguish from sibling tools like 'click' or 'search_html'.
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 provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires a loaded page), exclusions, or compare to siblings like 'click' for interactions or 'search_html' for finding elements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tests the given Autoconsent rule on the given URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to navigate to | |
| rule | Yes | Autoconsent rule (AutoConsentCMPRule) |
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 but offers minimal information. It mentions testing an Autoconsent rule on a URL but doesn't describe what happens during testing (e.g., whether it simulates user interaction, returns success/failure, or has side effects like navigation). 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, efficient sentence that directly states the tool's function without any unnecessary words. It is front-loaded and appropriately sized for its purpose, 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 complexity of testing rules on URLs, the lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., test results, errors) or any behavioral details like error handling or performance implications. This leaves the agent with incomplete context for effective use.
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 description coverage is 100%, so the schema already documents both parameters ('url' and 'rule') adequately. The description adds no additional meaning beyond what the schema provides, such as explaining what an 'Autoconsent rule' entails or how the URL is used. This meets the baseline for high schema coverage but doesn't enhance parameter 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 tool's purpose with specific verbs ('Tests') and resources ('Autoconsent rule', 'URL'), making it easy to understand what the tool does. However, it doesn't differentiate this tool from its siblings (like 'evaluate' or 'click'), which prevents 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 like 'evaluate' or 'click', nor does it mention any prerequisites or contextual constraints. It simply states what the tool does without indicating appropriate usage scenarios.
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.
clickevaluatenavigateprint_elementreloadreset_browser_datascreenshotsearch_htmlselecttest_ruleMost tools have distinct purposes, but 'evaluate' and 'test_rule' could be confused as both involve executing code or rules in the browser context. The other tools like 'click', 'navigate', and 'screenshot' are clearly differentiated by their specific actions on web pages.
The naming is mixed with some tools using verb_noun patterns like 'print_element' and 'search_html', while others are single verbs like 'click' and 'reload'. There is no consistent convention across all tools, but the names are generally readable and descriptive of their functions.
With 10 tools, the count is well-scoped for a browser automation and testing server. Each tool appears to serve a specific purpose in interacting with web pages, such as navigation, element manipulation, and data resetting, making the set comprehensive without being overwhelming.
The toolset covers core browser automation tasks like navigation, interaction, and inspection, with notable tools for Autoconsent-specific testing. A minor gap is the lack of tools for handling pop-ups or alerts, which are common in consent management scenarios, but agents can work around this using existing tools like 'click' or 'evaluate'.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A Model Context Protocol server for Wix AI tools
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Browser-based QA for AI-built software. Test pages with real browsers via agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/noisysocks/autoconsent-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
