Provides a GitHub Action for running CookieGuard's Set-Cookie header checks in CI, enabling automated cookie security validation during builds.
A successful agent login is not a secure session cookie.
Browser Use integration · MCP server · CI guide · Website
Quick start · How it works · Your policy · What it checks · MCP · Coding agents · More tools · FAQ · Documentation
pip install cookieguard
CookieGuard for Browser Use is a community integration, not an official Browser Use package. Audit only applications you are authorized to test.
Real run: Claude (claude-opus-5-5) drives a Browser Use agent through the same login twice. The insecure app gets FAIL — CG001 (exit 1); the secure app gets PASS (exit 0). Recording and test evidence
Your AI agent can log in to an app successfully while the session cookie it receives
is still unsafe, for example readable by JavaScript because it lacks HttpOnly.
CookieGuard watches the browser the agent drives, checks the authentication cookies
against your policy, and returns PASS / FAIL / INCOMPLETE with rule IDs,
explanations, and fixes.
The decision comes from the local CookieGuard engine and is enforced by your code, never by the model. Cookie values stay on your machine: they never reach the model, logs, or reports.
Needs Python 3.11+, Node.js 24+, and Chrome or Chromium. Install version 0.2.0:
pip install cookieguardCode that uses cookieguard-browser-use or import cookieguard_browser_use keeps working:
that package now installs cookieguard and re-exports it.
Runs a real Browser Use agent against a local login app, with no API key needed:
python -m cookieguard.browser_use.demo # insecure: FAIL CG001 (exit 1) · secure: PASS (exit 0)from browser_use import Agent, BrowserProfile, BrowserSession, Tools
from cookieguard import CookieGuardAudit
audit = CookieGuardAudit(
allowed_origins=['http://127.0.0.1:3000'], # exact origins you are authorized to test
auth_cookies=['session_id'], # the real session cookie name(s)
fail_on='high',
)
session = BrowserSession(browser_profile=BrowserProfile(
keep_alive=True, # required: Agent.run() otherwise closes the browser
enable_default_extensions=False, # avoid the bundled cookie-consent extension
allowed_domains=audit.browser_allowed_domains(),
))
tools = Tools()
audit.register_tools(tools) # optional agent-visible check
await session.start()
await audit.start(session) # before the login
agent = Agent(task=..., llm=..., browser_session=session, tools=tools,
sensitive_data={'http://127.0.0.1': {'login_password': '...'}})
await agent.run()
result = await audit.finish() # decided by the CookieGuard engine
await session.kill()
print(result.summary)
result.assert_policy() # raises CookiePolicyError on FAIL or INCOMPLETEassert_policy() raises on FAIL or INCOMPLETE even if the agent never called the
audit tool, or reported success.
Install guide · Real-model example
Related MCP server: Security Hunter MCP
CookieGuard reads the agent's browser over its own connection. It sees both what the
server declared (Set-Cookie) and what the browser stored. The published CookieGuard
engine then evaluates that evidence locally.
Details
fail_on sets the line: a confirmed finding at or above it fails the run; anything
below is reported. Only cookies you name in auth_cookies can be confirmed.
All policy options
Rule | Checks | Severity | Policy option |
CG001 | Authentication cookie missing | high | always on |
CG002 | Authentication cookie missing | high | always on |
CG003 | Declared | medium |
|
CG004 |
| medium | review unless |
CG005 | Remaining lifetime above the limit | medium |
|
CG006 | Invalid | high | always on |
CG007 | A protection regressed since a baseline | high |
|
CG008 | Authentication role not confirmed | review | name it in |
CG009 | Evidence needs review | review | — |
These are configuration checks. PASS means the configured checks passed, not that the application is secure. Full rule table · Limits & privacy
The same published policy engine powers every tool:
Tool | Use it for | Get started |
Browser Use | AI agents that log in and run browser workflows | |
MCP server | Letting an AI client scan your app's | |
Agent Skill | Teaching coding agents when and how to add these checks | |
Playwright | Cookies created during login in your existing tests | |
CLI |
| |
GitHub Action | Header checks, a build summary, and a sanitized report | |
Browser extension | Inspecting cookies interactively in Chrome |
With Node.js 24+, scan a local endpoint that sets your authentication cookie:
npx cookieguard-ci@0.2.0 scan http://localhost:3000 --auth-cookie session_idThe CLI, Action, and MCP server do not log in or execute JavaScript. Use Browser Use or
Playwright for authenticated workflows. Every tool reports 0 for a pass, 1 for a
confirmed policy failure, and 2 for an incomplete audit. The MCP server reports it as
the exitCode result field.
The CookieGuard MCP server lets an AI client, such as a coding agent, check the cookies your app sets. It runs locally over stdio. Your configuration file fixes the allowed origins and policy; the client can only choose which URL or evidence file to audit.
@aiscihub/cookieguard-mcp
0.2.0 is on npm and in the official MCP Registry as io.github.aiscihub/cookieguard.
It needs Node.js 24+.
Try it from a clone of this repository, with no API key or browser. The demo connects a real MCP client to the server:
npm ci && npm run demo:mcpMCP tools: cookieguard_audit, cookieguard_capabilities, cookieguard_explain, cookieguard_policy, cookieguard_scan
Capabilities: 9 checks; allowed origins: 1; evidence files: enabled
secure: PASSED (exitCode 0)
missing-httponly: FAILED (exitCode 1) — CG001 Missing HttpOnly
preference: INCOMPLETE (exitCode 2) — expected-auth-cookie-not-observed
Explain CG001: Set HttpOnly on the authentication cookie at the server.
Evidence login-report.json: FAILED (exitCode 1); observed by server: noTo connect your own client, write a config file (like this example) with your app's origin and session cookie names. Then add the server to your client's MCP settings:
{
"mcpServers": {
"cookieguard": {
"command": "npx",
"args": ["--yes", "@aiscihub/cookieguard-mcp@0.2.0",
"--config", "/absolute/path/cookieguard.json"]
}
}
}Tool | What it does | Available in |
| Shows the allowed origins and the policy in force | 0.1.0 |
| Scans one allowed URL's | 0.1.0 |
| Describes the checks, this server's configuration, result meanings, and limits | 0.2.0 |
| Audits one allowed URL, or one sanitized report your own Browser Use, Playwright, or CLI run wrote to the configured | 0.2.0 |
| Explains a rule ID, incomplete reason, or error code | 0.2.0 |
Results never contain cookie values. The agent decides whether to call the tool, so enforce results in your tests or CI when you need a gate. MCP guide
The CookieGuard Agent Skill tells coding agents when a task calls for these checks (Browser Use or Playwright logins, CI gates, MCP clients), which integration to pick, and how to read the result without exposing cookie values. In Claude Code:
/plugin install cookieguard --marketplace aiscihub/cookieguard-aiFor Codex, copy skills/cookieguard-browser-auth-security to .agents/skills/ in your
repository or to ~/.agents/skills/. Other agents that read SKILL.md can use the same
folder, and npm run package:skill builds a ZIP of it for skill marketplaces.
Automated tools can read cookieguard.capabilities.json:
a versioned, machine-readable description of every check, input, output schema, exit
code, privacy property, and limitation. Output schemas are in schemas/.
npx cookieguard-ci@0.2.0 capabilities --json and npx cookieguard-ci@0.2.0 explain CG001
print the same information.
Agent discovery details
Its classifier and explanations run in your browser, with no backend required.
Download or clone this repository.
Open chrome://extensions/ and enable Developer mode.
Select Load unpacked, then choose the extension-standalone/ folder.
Open a site you are authorized to inspect, click CookieGuard AI, and select Scan Cookies.
The popup shows AI Engine Ready or Rule-Based Mode.
Extension JSON exports can include cookie values; review them before sharing. Extension and research background · Privacy
No. Your code calls audit.finish() and assert_policy(); the local CookieGuard engine
decides. The agent's optional cookieguard_audit tool is read-only and provisional. In
testing, an agent that falsely claimed success without logging in still got INCOMPLETE.
No. Values go only to the local engine over a pipe, and every result is value-free. The
tests check this with synthetic tokens. Your model provider still receives the task and
page content. Pass credentials through Browser Use sensitive_data, and set
ANONYMIZED_TELEMETRY=false to turn off Browser Use telemetry.
Limits & privacy
Use Browser Use when an agent logs in and you need the browser's evidence: it sees the
cookies created during the real workflow, and your code enforces the result. Use the MCP
server to let an AI client check the Set-Cookie headers an endpoint returns, without a
browser or login. Its result is information for the agent, not an enforced gate.
Any model Browser Use supports. Verified with claude-opus-5-5, using Anthropic's
server-side fallback for intermittent safety-classifier refusals. The OpenAI and Browser
Use Cloud paths in the example have
not been run yet. The demo needs no model at all.
Only one you are authorized to test. Loopback origins are allowed by default. Others
need their exact origin plus allow_nonlocal_origins=True. CookieGuard never
navigates; use allowed_domains to keep the agent on the app.
Ubuntu 23.10+ blocks the user namespaces Chromium's sandbox needs. Run
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0, or use Google Chrome with
BrowserProfile(channel='chrome'). Avoid --no-sandbox.
Install guide
Version 0.1.0 is tested with Browser Use 0.13.14 and Chromium-family browsers:
Linux (GitHub ubuntu-latest): Python 3.11, 3.12, and 3.13, Node.js 24, Chromium 156.
macOS (Apple silicon): Python 3.12, Node.js 24 and 26, Chrome 156.
Windows, Browser Use cloud browsers, and other Browser Use versions are not tested yet. Tested environments and dependencies
Area | Guides |
Browser Use | Overview · Install · Policy · How it works · Results · Limits & privacy · Demo & tests · Validation |
MCP server | |
CI tools | |
Extension & research | |
Project | Release notes · Contributing · Troubleshooting · Security · Privacy |
The original CookieGuard AI extension won the Girls Who Code Challenge 2026: award announcement · original demo. CookieGuard is released under the MIT license.
Audit authentication-cookie configuration with the fixed startup policy. Pass exactly one of: url (GET one URL on a configured origin and audit its Set-Cookie headers; makes network requests, sends no cookies or credentials) or evidenceFile (re-evaluate a sanitized CookieGuard JSON report that your own Browser Use, Playwright, or CLI run wrote to the configured evidence directory). Returns passed, failed, or incomplete (exitCode 0/1/2) with rule IDs and fixes, never cookie values.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTP(S) URL on a configured origin, without credentials, query, or fragment. Do not include secrets in the path. | |
| evidenceFile | No | Plain file name such as login-report.json inside the configured evidence directory. No paths. |
| Name | Required | Description |
|---|---|---|
| error | Yes | |
| issues | Yes | |
| status | Yes | |
| target | Yes | |
| summary | Yes | |
| exitCode | Yes | |
| findings | Yes | |
| provenance | No | |
| limitations | Yes | |
| schemaVersion | Yes | |
| omittedFindings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: network requests occur, no cookies or credentials are sent, and cookie values are never returned (only rule IDs and fixes). That is valuable for a tool flagged openWorldHint and destructiveHint. It doesn't explain why it is non-idempotent/destructive given the read-only framing, which is a small gap rather than a contradiction.
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?
Front-loads purpose, then the mode switch, then the return contract — a logical order with no filler. The parenthetical clauses are dense and make single sentences long, but each carries information an agent needs.
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?
Despite an output schema existing, the description still states the outcome vocabulary (passed/failed/incomplete, exitCode 0/1/2) and what is returned (rule IDs and fixes, never cookie values). Combined with the origin/evidence-directory constraints, an agent has everything needed to call it correctly on the first attempt.
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 coverage is 100%, so the mechanics of both parameters are already documented, establishing a baseline of 3. The description does add the mutually-exclusive constraint absent from the schema (no oneOf, zero required parameters) and clarifies the behavioral effect of each mode, which lifts it slightly above baseline.
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?
States a specific verb and resource ("Audit authentication-cookie configuration") plus the governing policy ("fixed startup policy"), and the two distinct operating modes make it clearly distinguishable from cookieguard_scan, cookieguard_policy, and cookieguard_explain.
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?
Gives an explicit selection rule for the two modes ("Pass exactly one of: url ... or evidenceFile") and the condition behind each (live GET on a configured origin vs. re-evaluating a report your own Playwright/CLI run wrote). It does not say when to prefer this over cookieguard_scan, so sibling routing is only partly covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe CookieGuard: the cookie checks it runs, this server's fixed origins and policy, result and exit-code semantics, integrations for authenticated browser workflows, privacy properties, and limitations. Takes no arguments and makes no network requests.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tools | Yes | |
| checks | Yes | |
| server | Yes | |
| privacy | Yes | |
| results | Yes | |
| limitations | Yes | |
| integrations | Yes | |
| authorization | Yes | |
| configuration | Yes | |
| schemaVersion | Yes | |
| capabilitiesUrl | Yes | |
| evidenceRequirements | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real value beyond them: it promises exit-code and result semantics in the response and explicitly confirms no network requests, which reinforces and explains the openWorldHint=false annotation rather than merely restating it.
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?
A single front-loaded sentence with a tight enumerated list of covered topics; every item maps to something an agent would want to know. The list is long but not padded with filler or restated name/title material.
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?
With an output schema present, the description does not need to detail return values, and it still signals the shape of the response (checks, policy, exit codes, limitations). For a zero-parameter introspection tool this is close to complete; only the explicit routing guidance relative to siblings 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?
There are zero parameters, so the baseline is 4. The description correctly states it takes no arguments, matching the empty schema with additionalProperties false, and leaves nothing ambiguous about invocation.
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 ('Describe') applied to a clearly bounded resource (CookieGuard itself), then enumerates the exact topics covered: checks, fixed origins/policy, result and exit-code semantics, integrations, privacy, limitations. This separates it from cookieguard_scan or cookieguard_audit, which act on targets rather than documenting the server, though it never names those siblings explicitly.
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?
'Takes no arguments and makes no network requests' implies this is a safe first call for orientation, but the description never states when to prefer it over cookieguard_explain or cookieguard_policy, nor that it should be called before a scan. Usage is inferable rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a CookieGuard rule ID (CG001-CG009), incomplete reason, error code, or status (passed/failed/incomplete): what it means, when it is confirmed versus review, and how to fix it. Static text only; no network or cookie data.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | For example CG001, expected-auth-cookie-not-observed, TARGET, or incomplete. |
| Name | Required | Description |
|---|---|---|
| error | Yes | |
| knownIds | Yes | |
| explanation | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, so the bar is lower, and the description still adds real behavior: 'Static text only; no network or cookie data' tells the agent this cannot probe a live site, and 'what it means, when it is confirmed versus review' previews the answer shape. What is missing is the failure mode for an unrecognized ID.
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?
A single front-loaded sentence covering scope, accepted inputs, answer content, and the static/no-data constraint. There is no filler and nothing buried after the useful part.
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 one-parameter, read-only lookup with an output schema that documents return values, the description covers everything an agent needs to call it correctly. Only the unknown-ID behavior is left unstated, which is a minor gap.
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 coverage is 100% and the single parameter is already documented with examples, so the baseline is a 3. The description earns a step up by classifying the otherwise loose 'id' string into four semantic families (rule ID, incomplete reason, error code, status), which tells the agent what kinds of tokens are legal.
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 resource ('Explain a CookieGuard rule ID') and enumerates the accepted ID classes (CG001-CG009, incomplete reason, error code, status). It never names a sibling, but 'Static text only; no network or cookie data' implicitly separates it from the executable tools cookieguard_scan/audit/policy.
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?
Use is implied rather than stated: the agent can infer 'call this when you have an ID and need its meaning.' The clauses about 'confirmed versus review' and 'how to fix it' describe the content of the answer, not when to choose this tool over a sibling, and no exclusion or prerequisite is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the maintainer-configured origins, cookie policy, timeout, and HTTP-only scope. This tool cannot change them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description nonetheless adds the meaningful fact that the configuration is maintainer-controlled and cannot be mutated through this tool, which preempts an agent trying to write settings here. It also enumerates the returned fields, which matters because no output schema exists.
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?
Two short sentences with no filler: the first front-loads what is returned, the second immediately kills the mutation expectation. Nothing is repeated from the annotations or schema in a wasteful way.
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 zero-argument read tool with no output schema, the description supplies the key missing piece by naming the four returned configuration fields. It stops short of describing the response shape (nesting, types) or failure modes, but nothing an agent needs to invoke it correctly is absent.
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 takes zero parameters, so there is nothing for the description to disambiguate; the schema baseline of 4 applies. The description correctly makes no parameter claims that would conflict with the empty, additionalProperties=false schema.
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?
States a specific verb ("Read") and enumerates the exact configuration it returns: maintainer-configured origins, cookie policy, timeout, and HTTP-only scope. It is clearly distinct from scanner-style siblings like cookieguard_scan or cookieguard_audit, though it never names a sibling explicitly.
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?
Usage is implied rather than stated: an agent can infer this is the way to inspect current configuration before or instead of scanning. There is no explicit when-to-use guidance and no routing to cookieguard_capabilities or cookieguard_explain, so the agent must infer the boundary between this and the config-adjacent siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GET a URL on a configured origin and audit Set-Cookie headers with the fixed policy. Returns passed, failed, or incomplete (exitCode 0/1/2). Makes network requests; use authorized test endpoints. No login or browser cookies are collected. Same as cookieguard_audit with url.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTP(S) URL on a configured origin, without credentials, query, or fragment. Do not include secrets in the path. |
| Name | Required | Description |
|---|---|---|
| error | Yes | |
| issues | Yes | |
| status | Yes | |
| target | Yes | |
| summary | Yes | |
| exitCode | Yes | |
| findings | Yes | |
| provenance | No | |
| limitations | Yes | |
| schemaVersion | Yes | |
| omittedFindings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety bar is partly covered. The description adds genuinely useful context beyond them: outbound network requests occur, only authorized test endpoints should be targeted, and no login or browser cookies are captured, which softens the destructive hint meaningfully. It does not, however, explain why a GET-based audit is flagged destructive.
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?
Four tight sentences, front-loaded with the core action and result states. The closing 'Same as cookieguard_audit with url' is the one slightly wasted/ambiguous line, but overall there is little fat.
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?
An output schema exists, yet the description still usefully names the passed/failed/incomplete outcomes and exit codes. The network/authorization caveat covers the openWorld risk; only the mismatch between a GET audit and destructiveHint=true is left unexplained.
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 coverage is 100% and the url parameter is fully documented (no credentials, query, or fragment; length bounds). The description reinforces the 'configured origin' constraint but adds no syntax or format detail beyond the schema, so baseline 3 applies.
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?
Specific verb+resource: 'GET a URL ... and audit Set-Cookie headers with the fixed policy' tells an agent exactly what happens. It references the sibling via 'Same as cookieguard_audit with url', but that phrasing is ambiguous about how the two actually differ, so differentiation is present but not crisp.
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?
'Makes network requests; use authorized test endpoints' gives a real precondition. However, there is no explicit when-to-use-this-vs-cookieguard_audit guidance beyond the vague 'Same as cookieguard_audit with url', and no statement of when-not to use 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.
v0.1.0cookieguard_auditcookieguard_capabilitiescookieguard_explaincookieguard_policycookieguard_scanScored across 5 tools
cookieguard_scan is explicitly documented as 'Same as cookieguard_audit with url,' so two of five tools perform essentially the same operation, forcing the agent to guess which to pick. The other three (capabilities, explain, policy) are clearly distinct from each other and from the audit tools.
All tools follow a strict cookieguard_<verb/noun> snake_case pattern with a uniform server prefix. The suffix conveys intent (audit, scan, explain, policy, capabilities) predictably.
Five tools is well-scoped for a focused cookie-auditing server: an action, a duplicate action, and three informational/introspection tools. Nothing feels bloated or padded.
The surface covers auditing (URL and evidence file), rule explanation, capability discovery, and policy inspection, which is a coherent read-only lifecycle. Configuration mutation is absent, but that appears intentional since policy is maintainer-fixed; the only real redundancy is the audit/scan duplicate rather than a gap.
Cookie consent scanner: GDPR, CCPA, GCMv2. PASS/FAIL compliance checklists with fix recommendations.
Give your AI agent a clear picture of a website's privacy and tracking behavior. CertScore.ai checks public websites for cookies, trackers, consent controls, privacy-policy disclosures, and transport-security signals, then returns prioritized findings, retained evidence, and a shareable report. Use it before a website launch, when reviewing a vendor, or to investigate tracking and consent behavior. Start with CertScore MCP Light—no account, API key, or OAuth setup required. Try asking your agent: "Check my website's privacy and tracking behavior. Show me the top findings, supporting evidence, and report link." The simple three-tool workflow scans the site, checks progress, and retrieves the results. Connect in minutes: https://certscore.ai/mcp/light
EU cookie-consent & tracker audit, run like a real first-time visitor (EU proxies). Free quick check, no account. Finds trackers and tracking cookies before consent, missing first-layer Reject, what still fires after Reject, Google Consent Mode v2 state per signal, plus Google Fonts/YouTube/Maps/reCAPTCHA. Every finding comes with the exact request as evidence and a concrete fix, in 13 languages. Weekly monitoring, white-label PDF for agencies, private share links. Works with any CMP (Cookiebot, Usercentrics, Complianz, CookieYes, Borlabs…).
Agent security: prompt injection, PII & secret scans, TLS/header/CORS audits, MCP checks. Free.
