Skip to main content
This page documents what the Katla MCP server can do. To connect it to your assistant, start with the MCP server guide.

​
Endpoint

Streamable HTTP, authenticated with OAuth 2.1 (PKCE, dynamic client registration). Sign-in is delegated to the same identity provider the dashboard uses.

​
Tools

​
Teams

​
Sites

​
Accessibility

​
Cookies and consents

​
Policy

The policy text is generated from the latest scan, so it cannot be edited, only its company details, format (full, cookie policy or cookie table), language and styling. The embed renders unstyled HTML into the page, so it takes the site’s own CSS; see policy embed for classes and inline styles.

​
Free checks

​
Install guides

Sites can be referenced by domain (example.com) or by site ID - the assistant resolves either. If you belong to more than one team, it asks which team to use. The two free checks are the exception: they take a URL and read nothing from your account.

​
Asynchronous operations

Scanning is a queued job, not an immediate result. After starting one, the assistant polls katla_get_scan_status rather than assuming it finished. Scans count against your plan quota.

​
Free checks on any URL

katla_check_cookies and katla_check_consent_mode are the checkers from katla.app/tools exposed as tools. They take any public URL, including sites that are not in your team, and they spend no scan quota. Both load the page as a first-time visitor, accept the banner if there is one, and report what changed in between:
  • Cookie check returns the cookies set before and after consent, the third-party hosts, and a graded verdict. nonEssentialBeforeConsent is the number regulators act on: cookies that needed consent and were stored before the visitor gave any.
  • Consent Mode check scores four requirements - a default state set before Google tags load, the v2 parameters, an update sent when the visitor chooses, and the region and wait_for_update settings - and shows the gcs signal Google actually received before and after consent.
A check takes up to a minute. The tool waits for the result itself (waitSeconds, 40 by default) and returns with the check still running if it takes longer; calling again with the same URL picks that check up rather than starting a second one. Each account can start 10 new checks an hour, and a repeated URL returns the cached result without counting against that. Both cover a single page, and check the wiring rather than whether the site is compliant. Every result carries an interpretation block saying what the numbers do and do not mean, which the assistant is told to pass on rather than gloss over. For a site in your team, katla_scan_site builds the full multi-page inventory instead.

​
Installing Katla in your code

When you ask a coding agent to add Katla to a project, it reads katla_get_skill before writing anything, so it uses the real package names, props and script URLs rather than guessing at them. There are four skills:
  • katla-widget - the hosted banner: one script tag in <head>, a cookie settings link and the policy embed. The default choice, and all the banner’s styling stays in your site settings.
  • katla-sdk - a custom implementation with @katla.app/sdk: the React or Next.js provider, hooks, and a banner built from your own components. The agent uses it only when you ask for the SDK or a custom banner.
  • katla-policy - the privacy and cookie policy Katla generates from your scan, on a page of your site: the policy embed, styled like your other pages and linked from the footer and the banner.
  • katla-accessibility-widget - the accessibility widget: one script tag, its statement and feedback links, and translated labels. The skill tells the agent never to describe the widget as making a site accessible or compliant.
An install with katla-widget does not stop at the tag. The agent offers to match the banner to your site: the palette the scan read from your homepage, or the colours in your code, shown to you first and saved only when you agree. It then asks you to publish and to ask for one more scan, because only a scan of the published site can confirm the guard is live. katla_get_scan_status reports what that scan saw. Each skill is a SKILL.md plus reference files, fetched with the optional file argument (for example references/react.md). The same files are published as MCP resources under katla://skills/{skill}/{file} for clients that can attach resources to a conversation. In Claude Code and Codex, the Katla plugin installs the same four skills alongside the server.

​
Accessibility results

Every scan audits each page it crawls against WCAG 2.0/2.1/2.2 Level A and AA, and maps what it finds to both WCAG success criteria and the EN 301 549 clauses the European Accessibility Act is assessed against. katla_get_accessibility is available on every plan and returns the totals plus each rule that failed. katla_get_accessibility_findings returns the individual elements and needs the Pro or Business plan - the summary carries detailAvailable so the assistant knows before it asks. Two things the assistant is told to pass on rather than gloss over. Automated testing finds roughly 57% of real accessibility problems, so no scan result is a conformance claim. And results reported as incomplete are ones the scanner could not decide - contrast over a background image, a link whose purpose depends on surrounding prose - which need a person to review them rather than being lesser failures. Katla writes and translates a description for every cookie it recognises. When you want your own wording instead, katla_set_cookie_description replaces it for one language at a time:
“On example.com, describe the _ga cookie in German as ‘Unterscheidet Besucher in unserer Analyse’ and in Swedish as ‘Skiljer besökare åt i vår analys’.”
Your text is used by the consent banner, the cookie policy and the exports wherever that language is served. Languages you have not written keep the automatic description, so a German page never falls back to English wording. It also works for cookies Katla does not recognise, which otherwise have no description at all. The same overrides can be managed in the dashboard and with katla cookies describe.

​
Permissions and privacy

  • Scoped to your account. The connector can only reach teams you are a member of, and role checks apply per action - a member cannot do what an admin can.
  • You approve every connection. After signing in, Katla shows which app is asking, where its access will be sent and what it will be able to do, and connects nothing until you approve. App names are chosen by whoever registered the app, so check the destination.
  • Read and write scopes. Connections are granted katla:read and katla:write by default. A client that requests only katla:read gets a read-only connection, and every mutating tool refuses.
  • No billing. Plans and payments are deliberately not exposed. katla_get_scan_status tells you how many scans your team has left, and nothing else about the plan. Manage billing in the dashboard.
  • No destructive operations. Removing a domain is not exposed over MCP.
  • Free checks reach outside your account. katla_check_cookies and katla_check_consent_mode fetch whatever public URL you give them, so that URL leaves your account. They read nothing from your team and write nothing to it.
  • No visitor PII. Consent records returned over MCP include the consent decision, categories, and timestamp - never IP addresses or user agents.
  • Revocable. Remove the connector in your assistant to stop it being used, or sign out of Katla everywhere to invalidate the underlying session.

​
Self-hosted or staging

If you run Katla against your own API, point the connector at that origin instead:
Set API_PUBLIC_URL on the API to the public origin clients will reach. It is used as the OAuth issuer and as the MCP resource identifier, so it must match the URL you connect to exactly - otherwise discovery fails. Sign-in is handed to WorkOS AuthKit, which sends the user back to https://<your-api>/oauth/callback. Add that URL to the Redirect URIs of the WorkOS environment the API uses - without it every client fails at sign-in with a generic “Couldn’t sign in” page from WorkOS. To check discovery is working, https://<your-api>/.well-known/oauth-protected-resource/mcp should return JSON whose resource field matches the URL you entered.