Skip to main content
Glama

Set the banner mode

set_banner_mode
Idempotent

Sets which privacy regulation one of your CookiePal domains’ banner follows: gdpr, ccpa or both, where both applies GDPR everywhere and CCPA to US visitors at the edge. It changes nothing else about the banner, and then queues a rebuild so the change goes live; if the domain has reached its page-view limit the rebuild is skipped, and the result says so.

Input Schema

NameRequiredDescriptionDefault
domainIdNoWhich domain to change. Omit it for the account’s default domain.
bannerModeYes

Output Schema

NameRequiredDescriptionDefault
messageYes
rebuildYes
domainIdYes
bannerModeYes
bannerEnabledYes
previousBannerModeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the side effect (queues a rebuild so the change goes live), the failure mode (rebuild skipped when the domain hits its page-view limit), and that the result surfaces that condition. It also clarifies the edge-routing semantics of 'both' rather than leaving the enum opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then the constraints and side effects; every clause carries information. It is a single long chained sentence, though, so the rebuild and page-view-limit caveats would read better as a separate sentence.

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

Completeness5/5

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

With an output schema handling return shape and annotations covering idempotency and safety, the description supplies exactly the missing behavioral layer: side effects, the page-view-limit edge case, and enum semantics. Nothing needed 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: domainId is documented in the schema but bannerMode's enum values are not explained there. The description fills that gap precisely, defining gdpr, ccpa, and 'both' as GDPR everywhere plus CCPA to US visitors at the edge, which is real added meaning.

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

Purpose5/5

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

Names a specific verb (sets) and resource (which privacy regulation a CookiePal domain's banner follows), and enumerates the three modes. It is clearly separable from siblings like customise_banner or regenerate_banner, which touch other banner aspects.

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

Usage Guidelines4/5

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

The description scopes the change tightly ('changes nothing else about the banner'), which implicitly tells the agent to reach for customise_banner or regenerate_banner for other edits. It never states explicit when-not conditions or names those alternatives, so it stops short of full routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources