How to connect ConsentStack with OpenCode

List every team the authenticated user belongs to and the sites in each, with the user's role and each site's plan. Call this first to find the teamSlug and siteSlug other tools require.

Orientation for one site: plan and full entitlement matrix (which features the plan allows, with upgrade hints for gated ones), MAU usage vs cap, domains and verification status, pending config drafts per section, published config version, and setup checklist. Call this before configuring so you design within the site's plan limits.

Read the site's consent configuration. view=published (default) returns what is live; view=draft overlays any pending unpublished section drafts. Optionally narrow to one section: appearance, content, categories, or settings.

Stage appearance changes (layout, colors, fonts, spacing, customCss, customJs) as a draft. Partial patch: include only fields to change. Nested objects deep-merge over the current draft (or published config if no draft exists). Arrays replace wholesale, so send the complete array when changing one. The merged section is fully re-validated. Read the current values with get_config section=appearance first. Custom CSS and JS are plan-gated, check get_site_overview entitlements. Nothing goes live until publish_config.

Stage banner and preferences copy changes (titles, descriptions, button labels, links, per-consent-model overrides) as a draft. Partial patch: include only fields to change. Nested objects deep-merge over the current draft (or published config if no draft exists). Arrays replace wholesale, so send the complete array when changing one. The merged section is fully re-validated. Read current values with get_config section=content first. Nothing goes live until publish_config.

Stage compliance changes as a draft: consent categories, regions, consent rules (which consent model applies per category and region), language configuration, the global compliance flag, and surface visibility. This is the "categories" config section. Surface visibility is bannerVisibility, reentryVisibility (arrays of consent models, each a prefix of ["opt_in","opt_out","notice","notice_required"]; [] means the surface never shows). Partial patch: include only fields to change. Nested objects deep-merge over the current draft (or published config if no draft exists). Arrays replace wholesale, so send the complete array when changing one. The merged section is fully re-validated. categories, regions, consentRules, and the two visibility lists are arrays and replace wholesale, fetch them with get_config section=categories, modify, and send the complete arrays. Enabling more than one language is plan-gated (multiLanguage). Nothing goes live until publish_config.

Stage behavior toggle changes as a draft: geoDetectionEnabled, crossDomainConsent, consentTtlDays (1 to 3650 or null), strictFallbackEnabled, disableConfigCaching, showBranding (turning branding off is plan-gated), exposeGeoDetails, gpcMode ("always" honors GPC signals everywhere - the default, "required_only" honors only where statutorily required, "off" disables automatic GPC handling). testMode (when true, real visitors see no banner and nothing is blocked, but tracker detection and visitor counts keep working. Add ?cs-test-mode=true to a page load to see the banner yourself, for pre-launch validation). Whether the banner and the preferences button appear is no longer set here, it is bannerVisibility / reentryVisibility on update_compliance. Partial patch: include only fields to change. Nested objects deep-merge over the current draft (or published config if no draft exists). Arrays replace wholesale, so send the complete array when changing one. The merged section is fully re-validated. Nothing goes live until publish_config.

Publish pending config drafts, making them live for real site visitors. IMPORTANT: before calling this, summarize every pending change to the user in plain language and get their explicit go-ahead in this conversation. Publishes all pending section drafts unless sections narrows the set. Config regeneration and automatic translation run after publish.

Delete one section's pending draft without publishing it. The live config is unaffected. Confirm with the user before discarding work they may want.

Inventory of trackers the SDK has observed on this site: catalog products (with vendor, default category, the effective category after any manual override, script domains, cookie counts), script domains not matched to the catalog, free-standing manual rules, hostname ignore/block lists, and the valid category ids for set_tracker_category.

Categorize a tracker so the SDK gates it behind consent for that category. Target a catalog product by productId (one rule per catalog row of the product: host and path for path rows such as www.google.com /maps/, the whole host for hosts the product alone owns; whole hosts other services share are skipped and reported) or a whole host by domainPattern. This is the fix for scan findings where a tracker fired after reject (leaky) or before consent (pre_fence). Category must be one of the site's category ids (see list_detected_trackers). Requires admin or owner role.

Remove the manual category rules for a catalog product (by productId; whole-host rules on hosts other services share are left alone and reported) or a whole-host rule (by domainPattern). The tracker falls back to its catalog default category. Requires admin or owner role.

Set a per-hostname policy: ignore (always allow, never gate; for trusted first-party hosts), block (always block regardless of consent), or clear (remove the hostname from both lists). The two lists are mutually exclusive. Requires admin or owner role.

Create a new site in an existing team on the Basic tier (free, no billing step). Optionally seed the first domain. Returns the site slug and public site key for the install snippet. Plan upgrades happen in the dashboard. Requires admin or owner role.

Manage the site's domains. Actions: list (all domains with verification status), add, remove, set_primary, check (re-read one domain's verification status). Verification is automatic, there is no DNS or meta-tag challenge: the domain verifies when the consent snippet first loads on it. Domain limits are plan-based; add returns a plan_gate error at the limit. Requires admin or owner role.

Scan one of this site's verified domains for consent compliance (EU and US visits, tracker and cookie behavior before and after consent choices). Defaults to the primary verified domain; pass domain to scan another verified domain. Budget: 5 scans per site per hour. Returns a scanId to poll with get_scan_result. Requires admin or owner role.

Status and structured verdict for a scan started with start_scan: overall score, per-regulation status, and per-region (EU, US) verdict, findings with remediation hints naming the MCP tools that fix them, and tracker and cookie outcomes.

Aggregated consent analytics for a site: KPIs (total events, impressions, consent rate, average time to action), daily or hourly trend, per-category acceptance rates, action breakdown (accept all, reject all, partial, acknowledge), device and country breakdowns. range: 24h, 7d, 30d (default), 90d. Plan-gated: available on Pro and Business.

Paginated consent decision records for a site, newest first: event type and action, categories chosen, regulation and region, device, page, timing. limit 1 to 100 (default 25), offset for paging. totalCount is exact under 10k rows and a fast estimate above. Plan-gated: available on Pro and Business.

The question set for the business profile (document=profile) or one policy: each question's key, kind, label, help, options, when it applies (showIf) and whether it is required, plus answerSchema (the exact JSON Schema the answers must satisfy), defaults, and the id and label lists the answers use. Use it to map what the user tells you, or the site's existing policy, into answers. No site needed.

Find a service by name (Stripe, Mailchimp, HubSpot) to add to a Privacy or Cookie Policy with update_policy_services. Use it for services the site cannot detect, such as payment, email and CRM tools that run on a server. Returns up to 15 matches with their productId.

A site's business profile (legal name, entity type, where it is formed, contacts, processing location, children rule, change notices) and law answers (US states, revenue and volume thresholds, EU, UK, Canada, Quebec, Australia), whether it is complete, every missing or invalid field by question, and the privacy laws the answers resolve to. Every policy reads this profile; it must be complete before a policy can be started or published.

One policy on one site: status, draft and published answers, starting answers when it has not been started, the services list (Privacy and Cookie Policies, as the dashboard editor shows it), pending review items worded for the user, recent versions with links, the hosted URL, layout, where the embed was last seen, and a revision to pass to publish_policies. Missing answers come from preview_policy.

Render the policy's saved draft as readable text, exactly as it would publish, or list the questions still unanswered. Show the user the text (or a summary of what changed) before asking for their go-ahead to publish. Returns the revision publish_policies needs.

Every site in every team you belong to (or one team): whether the business profile is complete, each document's status, version and pending reviews, where each embed was last seen live, and which published Privacy or Cookie Policies the banner does not link yet. Start here when working across many sites.

The paste-ready snippet for the page that should show a policy, with attribution set by the site's plan, its hosted URL, the layout, where to paste it on Squarespace, WordPress and Webflow, whether it has been seen live, and for Privacy and Cookie Policies whether the banner links it.

Change a site's business profile (answers) and law answers (lawIdentifier). Each is a partial patch merged over what is stored; null clears an optional field such as accountablePerson. The profile saves only when complete; otherwise nothing is saved and every missing field is returned. Never guess business facts: take them from the user or the site's existing policy and confirm them.

Stage answer changes on one policy's draft. Partial patch: nested objects merge over the current draft, arrays and plain values replace, and null clears an optional field. A document that has not been started begins from its starting answers (get_policy shows them); an empty patch starts it as they are. get_policy_questions has every key and the exact shapes. Services are changed with update_policy_services. Nothing goes live until publish_policies.

Change which services a Privacy or Cookie Policy names, applied in order: hide or show a listed service, rename it, add a catalog service the site cannot detect (find it with search_service_catalog), or remove one that was added by hand. The Privacy Policy names only analytics, advertising and security services. Saves the draft; nothing goes live until publish_policies.

Throw away a policy's unpublished draft: back to the published answers, or to not started when it never published. The live policy is unaffected. Confirm with the user first.

Choose how an embedded or hosted policy lays out its sections: accordion (each folds into a row visitors expand) or flat (all open). Applies to every pasted embed and the hosted page without a re-paste.

Copy one site's business profile and every started policy's answers to other sites in the same team. For each destination this replaces its business profile (law answers included) and its draft of every policy the source has started; published versions are never copied. Each destination is reported on its own. Every policy reads the business profile when it publishes, automatic updates included, so the source site's website addresses can reach a destination's live policies at its next automatic update: right after copying, correct each destination's website addresses with update_policy_profile, then preview and publish there. IMPORTANT: before calling this, list the destination sites for the user and get their explicit go-ahead in this conversation.

Publish one or more policies on a site, making them live on the hosted page and every embed. IMPORTANT: before calling this, show the user the preview (or summarize every change in plain language) and get their explicit go-ahead in this conversation; one go-ahead may cover a listed batch. Each document needs the revision from your latest preview_policy or get_policy, and is refused if it changed since. Documents publish in the order Privacy, Cookie, Terms, Disclaimer, Accessibility Statement, stopping at the first failure. Warnings name what is left: the banner link, the embed, open reviews.

Apply or dismiss one pending review item (listed by get_policy). Applying republishes the policy with the change; for a new-law question, pass the answers by key. Dismissing ("Leave out of policy") keeps the named services out of the policy; some items can only be applied. IMPORTANT: explain the item to the user in plain language and get their explicit go-ahead first, since either choice changes the live policy.

Keyword-search the ConsentStack documentation. Returns matching pages with title, url, and a snippet. Use get_doc with the doc slug (path after /docs/) to read a full page.

Fetch one ConsentStack documentation page as markdown by its slug, e.g. 'developers/javascript-api' or 'concepts/script-blocking'.

Platform-specific ConsentStack install guide with this site's real site key already substituted into the snippet. Returns ready-to-paste markdown. Platforms: generic, nextjs, react, wordpress, shopify, webflow, squarespace, wix, finsweet.