The application does one - rather complicated - task, with lots of business logic. There was no way we could rewrite it to include it directly into the website code. And because the application comes with its own Javascript and CSS, we decided to use an iframe to embed the application with clean isolation.

The company maintaining that application provided us with a version - running as a Docker container - where they had stripped all extra elements like the navigation, so that it would visually fit within the website. There was however no way for us to customise anything within the application.

iframe security

The promise of an iframe is to keep a clean security boundary between embedding page and embedded content. This means that it is by design not possible to call Javascript across the boundary.

Because injecting iframes could potentially trick a user into submitting data to an attacker (clickjacking), as the iframe may be from a different origin than the main page. Thus, to even render the iframe, the browser checks the Content-Security-Policy (CSP) HTTP header. That header has a field frame-src to control what may be included as an iframe. With this, I allowed the domain of the application to be included in iframes.

Content-Security-Policy: frame-src https://my-embed.com;

But not only does the including page need to allow an iframe. The page to be embedded also needs to allow being included with the frame-ancestors attribute of the CSP header. As we run the application Docker image under our control, I was able to add that header in the proxy that runs before the Docker image:

Content-Security-Policy: frame-ancestors https://my-website.com;

Several things to note:

• If you have other CSP rules, merge them with the rules, nginx will overwrite the header and not add to it
• Both options also support "self" to allow embedding resp. being embedded with the same webserver
• Prior to the CSP becoming a standard, there was an unofficial header X-Frame-Options, which is still supported by browsers
• Content-Security-Policy must be an actual HTTP header, <meta http-equiv=”...”> is ignored for Content-Security-Policy (and also ignored for X-Frame-Options).

Size of the iframe element

Now we get to the weird parts. To prevent multiple scrollbars, we need the iframe element to be exactly big enough for the embedded page. If it is too small, there is an additional scrollbar (or hidden content). If it is too large, there is odd whitespace.

The size of the element needs to be set on the iframe, owned by the parent. The dimensions of the content are however only known by the embedded application. HTML / CSS do not provide any means to let the parent page declare that it wants the iframe to have the “necessary size”.

We ended up with a really convoluted way, which seems the only way to achieve this: sending messages from the child page to the parent. This problem spawned dedicated javascript libraries like iframe-resizer. We ended up reimplementing the logic in the React application, as it was so small that a dedicated library felt like overkill. Following the tutorial at iframe-height (which also has some interesting background on the discussion about iframes in the Whatwg), we came up with this code for the containing website:

// register an event listener for messages
window.addEventListener('message', receiveMessage, false);

// handle a message
function receiveMessage(event) {
    const origin = event.origin || event.originalEvent.origin;
    // we configure the expected domain to allow for this additional sanity check
    if (expectedDomain !== origin) {
      return;
    }
    if (!event.data.request || 'iframeResize' !== event.data.request) {
      return;
    }
    // the id is known in the js class. we need to find the element that needs to be resized
    const iframe = document.getElementById(`iframe-${id}`);
    if (iframe) {
      // pad the height a bit to avoid unnecessary tiny scrolling
      iframe.style.height = (event.data.height + 20) + 'px';
      // width could be handled the same way if necessary - in our case the width is fix
    }
}

Now we need to make the embedded content send a message with its height. The Javascript for that is a bit verbose to allow for different browsers, but not complicated either:

(
    function(document, window) {
      if (undefined === parent || !document.addEventListener) {
        return;
      }
      function init() {
        let owner = null;
        const width = Math.max(document.body.scrollWidth, document.body.offsetWidth, document.documentElement.clientWidth, document.documentElement.scrollWidth, document.documentElement.offsetWidth);
        const height = Math.max(document.body.scrollHeight, document.body.offsetHeight, document.documentElement.clientHeight, document.documentElement.scrollHeight, document.documentElement.offsetHeight);
        if (parent.postMessage) {
          owner = parent;
        } else if (parent.contentWindow && parent.contentWindow.postMessage) {
          owner = parent.contentWindow;
        } else {
          return;
        }
        owner.postMessage({
          'request' : 'iframeResize',
          'width' : width,
          'height' : height
        }, '*');
      }

      if (document.readyState !== 'loading') {
        window.setTimeout(init);
      } else {
        document.addEventListener('DOMContentLoaded', init);
      }
      // this is needed to also adjust the iframe if something (e.g. the Javascript of the application) changes the size of the iframe without an actual page reload.
      const observer = new ResizeObserver(init);
      observer.observe(document.body);
    }
  )(document, window);"

iframes with same origin

If the iframe comes from the same origin (= domain) as the parent page, Javascript can cross the boundary. From parent to child, there is a contentWindow property on the iframe element. From child to parent, there is window.parent. With same origin, those elements expose all things the window usually has. For different origins, they only expose the function postMessage for the secure separation.

Injecting content with Nginx

Remember how I said we can’t modify the application? That still holds true. If we would have loaded both applications from the same domain, we could have had the parent page add a listener inside the iframe to directly update dimensions as needed. But the application contained absolute paths for its assets, so providing it from a subfolder of the same domain would have been tricky and we had to run it on a separate domain.

I ended up injecting the above snippet of Javascript in the Nginx proxy that sits in front of the Docker container:

proxy_set_header Accept-Encoding ""; # make sure we get plain response for substitution to work
...
sub_filter_last_modified on;
sub_filter "</body>" "<script language='javascript'>${script}</script></body>";
sub_filter_once on;
...
proxy_pass https://my-embed.com$request_uri;

Now the embedded iframe communicates its size to the containing page, which adjusts the iframe size accordingly.

(Note that Nginx does not execute these statements in order. The sub_filter instructions apply to the response, wihle proxy_set_header and proxy_pass apply to the request.)

Alternatives

Web Components are a more lightweight solution to combine separate sources into one website. If what you need to integrate is just an element and not a whole application, they might be a better fit. My collegue Falk wrote about Web Components last week.

Bonus: Access control for the iframe content

Because the application is not under our control, we need to manage access to it. We told the supplier of the application to remove access control and simply allow items to be created and edited by ID. Of course, this means that the application must never be directly exposed to the internet, but only reachable through the proxy.

On the embedding side, we track which user is allowed what ids, and have Nginx do a pre-flight check against the website to get the access decision:

# at the beginning of the location for the main request to the embeded application
auth_request /auth;

location /auth {
    # preflight authorization request with symfony
    fastcgi_pass phpfcgi;
    include /usr/local/openresty/nginx/conf/fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /app/public/index.php;
    # forward the original request URI to allow our main application to verify access to the specific resource
    fastcgi_param REQUEST_URI /embed-check$request_uri;
    # body is not forwarded. we have to remove content length separately, otherwise PHP-FPM will wait for the body until the auth request times out.
    fastcgi_pass_request_body off;
    fastcgi_param CONTENT_LENGTH "";
    fastcgi_param CONTENT_TYPE "";
    internal;
}

If the call at /embed-check/... returns a 2xx status, Nginx continues with the request, otherwise it returns the response with the status code to the client, allowing for example to redirect to the login page. In my case, i return an empty response with status 204 if the user is allowed to access the specific resource.

On Symfony side, I use Symfony security to make sure the user is logged in. And then parse the path to know which item in the application the request wants to access, and check if the user has access. This leaks knowledge about the URL design of the embedded application, which is not avoidable for granular access control.

Here are practical techniques to prevent it.

Session Hygiene

Start a fresh session for each task. This is the simplest technique and the easiest to get right. If earlier research is needed, write it into a temporary handoff file and let a new session pick up from there.

Streamline Tool Calling

Every tool call adds tokens to the context. Poorly built tools add a lot of them. To keep the context lean:

• Choose tools and MCPs that are well built and optimize token usage
• Make sure via prompting that the right tools are used from the start

A single bloated tool response can waste more context than an entire conversation turn.

Subagents

Agents can spawn other agents that run in their own context. This isolates work and keeps the parent context clean. It helps most when building large features where individual parts are independent.

The easiest way to use subagents is to prompt something like:

Split the current plan into tasks, use a subagent for each task.

Persistent Tasks

I built an MCP for Claude Code called deliverables-mcp that lets an agent create persistent tasks per codebase. Tasks are stored in .claude/deliverables.jsonl and persist across sessions.

This allows:

• Starting a new session before implementing each task
• Running subagents in parallel based on tasks dependencies
• Restarting a failed task in a clean session

The tool replaces Claude Code's internal tasks and is deliberately called "deliverables" for two reasons:

1. To avoid confusing the agent with two tools both called "tasks"
2. Deliverables are typically larger than just a task, which is a sweet spot for AI agents. Not so small that handoff cost dominates, but small enough that context problems are rare.

You can check out deliverables-mcp on GitHub.

An article published by the team behind the project in the latest issue of the Revue Médicale Suisse provides a first assessment one year after its public launch.

An official chatbot instead of unreliable answers online

Primary care, which is essential for a well-functioning healthcare system, is facing a growing shortage, even in urban areas. Without easy access to their primary care physician, many patients turn to the internet to search for answers. Unfortunately, the information they find is often inaccurate or even potentially harmful.

In this context, a well-designed AI solution can help deliver the right information at the right time.

This is why we supported HUG in developing a RAG-based chatbot (Retrieval Augmented Generation). ConfIAnce is not the first chatbot designed for patients. However, it stands out thanks to its institutional roots, its use of locally validated medical content, and the control layers implemented to ensure reliable responses.

To guarantee safety, the system integrates monitoring mechanisms, including matching, groundedness checks, harmfulness detection, automated testing, and semantic routing.

Keeping control of the tool to ensure quality

One key challenge is maintaining control over the system, which requires monitoring capabilities. To achieve this, automated tests are run on all answers generated in response to user questions.

These tests measure the factual consistency of the chatbot’s responses compared with the knowledge base.

In addition, adjustable routing rules allow administrators to maintain human oversight by filtering and directing questions appropriately. Administrators can also immediately take the chatbot offline if a malfunction is suspected.

Topics that are frequently asked about but are insufficiently covered in the source documents are identified. These are then developed further to enrich the knowledge base as part of a continuous improvement process.

Even the best tool is only useful if people use it

For the chatbot to be useful, patients need to use it. To support adoption, HUG ran a public information campaign that promoted the tool while setting realistic expectations about what it can do.

ConfIAnce is not a medical device meant to replace a consultation. Instead, it provides informational support for questions related to the most common chronic diseases affecting adults.

In February 2025, ConfIAnce was released in beta. Between early February and the end of October 2025: 3,823 users interacted with the chatbot, generating 5,969 conversations with 11,781 questions (about two questions per conversation)

Feedback provided directly through the chatbot is 75% positive.

Strong acceptance for a different kind of chatbot

Chatbots in healthcare journeys are generally well accepted by patients thanks to their constant availability and ease of use. However, studies highlight recurring issues: inconsistent response quality and a lack of transparency regarding sources.

These are precisely the aspects that differentiate ConfIAnce from many other medical chatbots.

Designed to support, not replace, the relationship between patients and physicians, ConfIAnce helps primary care doctors by freeing up time so they can focus on practising medicine with the human-centred approach that motivated them to choose this profession.

The chatbot, developed in the specific context of HUG and its information resources, could be adapted to other institutional settings.
For such a project to succeed, access to high-quality data is essential, as was the case here. Beyond that, control layers, automated testing, and user feedback enable continuous improvement and ensure the safety and relevance needed to build trust.

Our accessibility journey followed four main steps: automatic scans and quick-fixes, keyboard navigation, mobile zoom optimization, and screen reader experience.

Automatic Scans and Quick-Fixes

We started with automated accessibility testing using browser extensions like IBM Equal Access Accessibility Checker and axe DevTools. These tools helped us identify common issues: missing labels, insufficient color contrast, improper semantic HTML, and missing ARIA attributes. While automated scans only catch about 40% of accessibility issues, they provided a solid foundation for our work.

Keyboard Navigation

Proper keyboard navigation is fundamental to accessibility. Ensuring basic Tab navigation works across the app is straightforward, but more complex components like tabs, menus, and modals require advanced keyboard interactions: arrow keys, Escape key handling, and focus management that follow official W3C guidelines. Users who rely on keyboard navigation have learned to expect these specific patterns, and deviating from them creates confusion and frustration. Rather than building these patterns from scratch, we leveraged Bits UI, a headless UI library that implements these accessibility guidelines correctly.

Beyond individual components, we implemented focus loops and focus restoration at the application level to keep users oriented as they move through different stages of the chat interface.

Mobile Zoom Optimization

During user testing for meinplatz.ch with users who have disabilities, we observed something striking: many users navigate websites on mobile devices with 200% or more zoom, holding their devices just 10cm from their eyes. This insight highlighted a critical gap in most chatbot implementations.

Most chatbots use fixed-position elements: a chat input at the bottom and often a header at the top. When users zoom in significantly, these fixed elements can consume the entire viewport, making the interface unusable. Unfortunately, reliably detecting user zoom levels is impossible in browsers. Our solution: use Intersection Observer to detect when the header or footer take up more space than expected, then dynamically remove their fixed positioning to restore usability.

Screen Reader Experience

Screen reader accessibility isn't automatic: it requires careful design. We focused on providing clear context through proper page structure (landmarks and headings), ensuring users always understand where they are and what's happening, and provide them shortcut to the key parts of the app.

Providing Context

We implemented a comprehensive outline structure with landmarks for main navigation, settings, and input areas. Each message includes proper headings and labels, and we added a skip link after the chat input (at the bottom of the page) to help users quickly return to the top.

Web Component Challenges

Working with web components introduced unique challenges. VoiceOver is particularly sensitive to how libraries are implemented. We worked closely with the bits-ui team (who were very responsive to bug reports) and implemented local portals for dropdown menus to avoid VoiceOver navigation issues, for example.

Managing Announcements

One of the trickiest challenges was managing VoiceOver announcements when multiple events occur simultaneously. Since queuing announcements doesn't work reliably, we carefully sequenced events and merged related announcements. For example, when a user clicks "select all options" for a list, individual announcements for each option would normally fire and override each other. Instead, we cancel those separate announcements and replace them with a single clear announcement summarizing everything that happened (all items selected or deselected, reset to the predefined set of items, etc.).

Since the chat is a SPA without page reloads, it was also important to announce all changes that are only visually visible, for example: light/dark mode switch, language switch, etc.

Chat Flow for Screen Readers

We designed the chat experience specifically for screen reader users:

• The input field includes both a placeholder and an aria-label with the page title, providing context on page load since the input auto-focuses and users skip over the initial page content.
• When a response is being generated, we announce this clearly, providing the same feedback that a visual loading indicator would.
• Once a response is ready, it's read without markdown formatting (no bold, no links, etc.) to maintain a natural reading flow.
• After reading a response, we make users aware that they can ask another question directly or navigate to the last message's options to provide feedback or view references. We dynamically add this interactive section of the last message (where users are most likely to interact) to the document outline, creating a quick navigation shortcut.
• Chat history is structured as articles with labels, making it easy to navigate past conversations.

Try It Yourself

You can experience these improvements with Alva, the chatbot of the Basel-Stadt administration. Try navigating with VoiceOver (MacOS) or NVA (Windows), use only your keyboard, or zoom in significantly on a mobile device.

An ongoing journey

Our next goal is to integrate automated accessibility testing into our CI pipeline. However, as mentioned earlier, automated scans only catch around 40% of accessibility issues. This means we'll still need to carefully plan and test each new feature manually. Nothing replaces human testing when it comes to accessibility—automated tools can flag missing labels or contrast issues, but they can't evaluate whether an interface is actually usable for someone navigating with a screen reader or keyboard.

Accessibility is an ongoing journey, not a destination. We're committed to making LiipGPT usable for everyone, and we'll continue refining our approach based on real-world feedback.

Need Help with your Accessibility?

We offer accessibility audits to help you identify and fix issues in your own applications. If you're looking to improve the accessibility of your product, get in touch with us, we would be happy to help.

GovNL: From months to minutes to build sites

GovNL combines open source Drupal components and an open design system to run many Dutch government sites in a way that is accessible and scalable. It reduces time to build new sites from 3 months to about 10 minutes, pretty impressive to say the least. This is a strong use case of designing for reuse at large scale.

European Commission: Coordination is key to scaling

The European Commission already runs no less than 770 sites and invests heavily in the Drupal ecosystem! What stood out for me was how much they focus on coordination—making sure the right content is published through the right channel across that landscape. Open source program offices (OSPOs) were established as a way to drive open source agendas both at government level and inside organisations.

Kanton Basel-Stadt website and Alva: a blueprint for local public administration

Just before lunch break, it was time for me to present the different AI use cases we implemented for Kanton Basel-Stadt. The canton set new standards with the bs.ch relaunch with user-centred design, topic-based access instead of internal org structure, and Alva as the first AI-based chatbot for a Swiss canton. The stack is based on open source components and Liip heavily contributed to open source as part of this relaunch. We use Drupal as CMS, Nuxt/Vue, the blökkli editor for the headless frontend and Elasticsearch for search. Content is produced by a cross-department editorial team following a clear content strategy.

AI to support the public and editors of the website

The talk was an opportunity to share figures more than 18 months after the go-live. Today, Alva handles over 10,000 questions per month, with about 1.36 questions per conversation and +44% growth since Alva 2.0. API integrations let the chatbot answer questions based on real-time information. Alva is also used heavily by internal users from the canton as well as the public. The chatbot always shows and validates its sources, which is central to creating trust.

On the editing side, blökkli is working hard to simplify texts. By using the blökkli editor with integrated AI, editors can now run a readability audit, see proposed simplifications side-by-side and accept or adapt them. Alva and the AI features on bs.ch are continuously developed further to provide editors and citizens trustworthy AI technology.

AI assisted technologies at the French Government

Another inspiring talk to watch was Use-cases of AI in the Services Publics+ platform at the French government. With more than 140.000 experiences shared and over a million of reactions, the system uses AI assisted technology to help State service provide feedback to citizens. They leverage speech to text and real-time summaries as an enabling technology. C’est magnifique!

The EU trusts open source more than ever

The European Union introduced Website Evidence Collector that scans sites for security issues and is open source. It was notable that they publish it under the EUPL (European Union Public Licence), which emphasises interoperability between countries and licences and supports multilingual collaboration. I wonder if Switzerland has something similar?

Not only does the EU trust open source for security they also provide through Interoperable Europe a new portal there’s a useful Licensing Assistant. You can find and compare software licences and run a compatibility checker to see if different open source licences can be combined and whether there are legal complications.

Using open source is not enough, we need champions

Finally, Tiffany Farris from strategy consultancy Palantir.net (not to be confused with the infamous Palantir Technologies) stressed that using open source is good, but not enough. You need champions in the organisation who put contribution and ecosystem health on the agenda. Designing for reuse should be a core principle. From a US perspective, procurement is a problem: open source usage has grown, but support mechanisms often haven’t. Treating open source as “free” can lead to contracts going to vendors who brand their work as open source without actually supporting a thriving ecosystem. She proposed concrete public money, public code-style amendments to public procurement to better support the ecosystem. This was really an inspiring conclusion to an intense day of learning and exchanges.

You can watch the playlist if you would like to dive deeper into the presentations from Drupal4Gov EU 2026.

We created a fully themeable chat UI that can be embedded in any website and has no effect on the parent page. Kanton Basel-Stadts Alva and RAMMS' Rocky AI are instances of that UI.

This blog post will show you what we learned about creating web components that do not influence the parent page. Here are the good, the bad and the ugly when working with web components.

The Good

These are the good parts of web components. They will lay the foundation for why you might use them.

Portability

Every system that can handle HTML can handle web components. A simple tag and a script will integrate it into any web framework. It doesn't even need to be a JavaScript framework.

<body>
  <your-webcomponent></your-webcomponent>
  <script src="path/to/your-webcomponent.js"></script>
</body>

Native Feel

IFrames are another way to embed UI into a page, and they are arguably easier to use. But the main difference is that web components feel more native to the page, since they directly integrate into the parent page's layout. This means you can use transparency, intrinsic sizing (size based on the web component's contents), and seamless event communication with the parent page.

Slots

With slots you can provide content that will be added at a specified point inside your web component.

In our chat UI, we used a slot to let integrators provide a custom loading spinner. This spinner needs to be visible immediately, before the full theme loads asynchronously.

Shadow DOM - Isolating Styles

A robust way to ensure that your styles do not affect the parent page is to use the Shadow DOM. Shadow DOM is a web component feature to add a boundary for styles. Styles applied inside the Shadow DOM never apply to the parent page.

Caveat: Inheritable CSS Properties

There is one exception to the isolation where CSS properties of the parent page apply to the web component.

These are the properties that pierce through the boundary:

• Inheritable CSS properties like color, font-family, line-height
• CSS custom properties like --my-var

In practice, we have found it helps to fully specify the common properties like fonts and color on every element. That way you will never be surprised by different styles on integration.

Vite

For bundling web components, we can highly recommend Vite. There are a lot of neat tricks you can apply while bundling. Here are the Vite features we used for our web component.

Inlining Assets

Vite's explicit inline handling feature allowed us to inline our external CSS files into the JS bundle.

import cssContentString from "./index.css?inline";

This feature will not only inline the raw content of the imported index.css. It will also resolve all CSS imports, apply PostCSS transforms, and even work with CSS preprocessors like SASS. While inlined CSS is not the most efficient for browsers to render, the benefit is that we can ship a single JS file.

Library Mode

The Vite library mode provides you with fine-grained control of how the bundle should behave. To enable the library mode just add the build.lib option in your Vite config.

The Bad

Not everything about web components is great though. Here are the bad parts.

SSR - Hard to Get Working

Server-side rendering will almost certainly not work. The rest of the page can still be rendered server-side, but the web component will only show up as a <your-webcomponent></your-webcomponent> tag. Its contents will only be rendered in the browser.

There is one experimental package by Lit Labs that tries to solve this, but we never tried it.

Tailwind - Not a Great Fit

Tailwind feels like a natural choice for web components, but it does not play well with them.

The core issue is twofold. First, Tailwind ships its own CSS reset (called Preflight), which overrides default browser styles. When injected into a page that does not use Tailwind, it potentially breaks the page. Shadow DOM could isolate this reset, but Tailwind is fundamentally not designed to work inside a Shadow DOM. Here is the discussion if you are interested.

There are some hacky workarounds, but we tried them and had no success getting them to work reliably.

Our recommendation is to only use Tailwind if you are guaranteed that the parent page also uses it, and then use web components without Shadow DOM.

The Ugly

Verbose Web Components API

The native web component API is verbose and hard to read. A simple counter component, for example, requires manually defining a class, attaching a shadow root, setting up innerHTML, and wiring event listeners in connectedCallback. This boilerplate adds up quickly. You can see examples of the API here.

Fortunately, web components make for a great compile target. Svelte and Vue directly support compiling to web components. React is a bit trickier, but totally doable as well. We used this approach for our chat UI, where the first iteration was built with React and the current one with Svelte.

Weird Quirks

Advanced web component features come with edge cases that no documentation warns you about. Even Svelte, which has excellent web component support, ships with a notable list of caveats.

We even hit an undocumented edge case with slots in Svelte: the bundle script must load after the component markup, or slotted content will not render. An ugly wrapper for slots fixes the problem, but quirks like this add up and slow you down.

Font Loading - Not Working Inside Shadow DOM

When authoring web components, you get into the habit of defining all stylesheet links etc. in the web component body. As you should, so they do not affect the parent page. But there is another annoying detail here: @font-face will not work when defined in the Shadow DOM. If your web component needs a custom font, you need to inject the font CSS into the parent page to make it work.

Conclusion

I do not want to end on this ugly note though. I really think there are cases where web components are the right choice, and in our case we would choose Svelte & web components again.

To help you get started, here is a Svelte starter template.

The City of Zurich publishes over 900 datasets as open data, spread across six different APIs. There's CKAN for the main data catalog, a WFS Geoportal for geodata, the Paris API for parliamentary information from the Gemeinderat, a tourism API, SPARQL linked data, and ParkenDD for real-time parking data. All public, all freely available. But until now, making an AI assistant actually use these APIs meant writing custom integrations for each one.

The MCP server wraps all six APIs into 20 tools that any MCP-compatible AI assistant can call directly. Ask "How warm is it in Zurich right now?" and it queries the live weather stations. Ask about parking availability, and it pulls real-time data from 36 parking garages. It also covers parliamentary motions, tourism recommendations, SQL queries on the data store, and GeoJSON features for school locations, playgrounds, or climate data. All through a single, standardized Model Context Protocol interface.

Hayal Oezkan built it in Python using FastMCP. One file for the server with all 20 tool handlers. The repo is on GitHub.

Deploying it on our side took very little effort. The server supports both stdio transport for local use (like in Claude Desktop or Claude Code) and SSE and HTTP Streaming for remote deployment. I packaged it with Docker, deployed it to our cluster, and now it's available as a remote MCP server that anyone can add to their AI tools without installing anything locally.

The natural next step was integrating this with ZüriCityGPT. It happened, just not quite in the direction I originally had in mind.

ZüriCityGPT already had its own MCP server at zuericitygpt.ch/mcp, exposing tools for searching the city's website content, "Stadtratsbeschlüsse" and looking up waste collection schedules. Instead of wiring the open data tools into ZüriCityGPT, I went the other way: the open data MCP server now proxies tools from the ZüriCityGPT MCP server. A lightweight proxy client connects to the remote server via streamable-http and forwards calls. The whole thing is about 40 lines of Python.

So now, when you connect to the Zurich Open Data MCP server, you get 23 tools in one place. The 21 original open data tools across six APIs, plus zurich_search for querying the city's knowledge base and zurich_waste_collection for waste pickup schedules (based on the OpenERZ API). One MCP endpoint, many services behind it.

A city employee builds something useful in the open, publishes the code, and within a day it's deployed and available to a wider audience. Open data and open source working together, exactly as intended.

At the heart of the relaunch is user centricity. Instead of an internal, administration-driven perspective, a topic-centered structure is being created—similar to what the Canton of Basel-Stadt has already successfully established (more about the project in this blogpost).

From a content perspective, the initiative? A mammoth project.

What does a content project of this scale require?

Organically grown content cannot simply be migrated. A relaunch is usually the moment when content is not only transferred, but rethought in terms of quality.

Because a large volume of content needs to be revised, a decentralized editorial model is required. Numerous employees—often without in-depth content experience—are involved. Good processes, clear roles, and targeted support are therefore essential:

• A decisive project lead
• A solid inventory and assessment
• Concept and strategy
• Governance (processes & responsibilities)
• Set-up and training of the web editorial team
• Operational content production
• Quality assurance

Liip is accompanying the Canton of Graubünden on this journey. Based on our experience from projects in Basel-Stadt, Solothurn, and various federal offices, a trusting and efficient collaboration has developed.

How we work together

Two content strategists from Liip work closely with the canton’s project management. The project team contributes internal know-how and decision-making power, while Liip adds operational capacity and extensive experience from similar setups. This arrangement enables high speed—and a clean integration of internal knowledge and external input.

The collaboration spans already more than 1.5 years.

What are Liip's deliverables?

• Content audit
• Content strategy & tone of voice
• Content governance & editorial model (for the project phase and for ongoing operations)
• Content lifecycle model
• Content guidelines for the editorial teams
• Page types & sample texts (in collaboration with the design team)
• Word templates for content creation
• Training & support for editorial members
• AI-based writing tool “GR Editor” (based on TextMate)
• Quality assurance

What does this mean in detail? From audit to quality assurance

A relaunch involving more than 120 editors and thousands of pages of content needs one thing above all else: a clear implementation plan and thorough preparation. Each step builds on the previous one.

1. Content audit – creating clarity
   We started the project by analyzing a representative selection of existing content. The audit helped identify optimization potential and formed the foundation for all subsequent decisions.

2. The editorial model – roles, responsibilities, and processes
   Content governance and the editorial model we developed created the basic ideas for our work with the web editorial teams. We made a model for the project phase. We also added a plan for after the relaunch.

3. Content strategy & tone of voice – the guiding framework
   Governance regulates collaboration and processes; the content strategy defines the editorial direction. It is aimed less at editors and more at providing the conceptual and content foundation for operational elements. The strategy was complemented by two distinct tones of voice for the new website. With the strategy completed, the operational phase began.

4. Page types & sample texts – making the concept tangible
   Together with the design team, we developed the new page types. Our UX writer created initial realistic content that served as references for finalizing the page types. Working with real text is crucial: only this way can structure, content, and design be meaningfully aligned.

5. Content guidelines – the handbook for editors
   Derived from the content strategy, the content guidelines bundle rules, recommendations, examples, and concrete instructions—for clear, accessible, and consistent content.

6. Word templates – because the CMS is being developed in parallel
   Since CMS development and content creation run in parallel, texts need to be created outside the CMS. For this purpose, we created Word templates that: reflect the new page structure, integrate all relevant meta information, include guidance for editors. The Word templates were supplemented with visualizations of the individual page types. For each page type, a real text example was set up in Figma and shared with editors as a PDF.

7. AI writing tool “GR Editor” – real-time support
   A decentralized editorial model inevitably leads to varying text quality. The GR Editor (based on TextMate) counteracts this by checking clarity, consistency, and tone of voice directly while writing.
   The canton had ideal prerequisites: existing cantonal writing guidelines, the new content guidelines, and the two defined tones of voice.

8. Building the editorial teams & training
   First, the editorial teams were assembled to match the new website structure: a topic section and an organizational section. For the topic section, topic-based editorial teams were created, each with a coordinator. They act as an interface between the teams and the project management. The support organization (project management + Liip) accompanies the teams. The training sessions were the first practical entry point. The new page types, guidelines, and the GR Editor were introduced.

9. Editorial support – day-to-day guidance
   Content work is currently ongoing. The support organization hosts regular editorial meetings, answers questions, and develops solutions. Each topic team receives individual sparring on their first texts.

10. Quality assurance – before content goes live
    With this volume of content, personal responsibility is key. Editors receive checklists to review their own texts. Strategically selected content receives specific feedback. The GR Editor also makes a significant contribution to quality assurance.

Initial learnings from the project

A relaunch of this size stretches everyone involved. A decentralized editorial model is unavoidable. Understanding the situation of editorial team members, flexibility in implementing the plan, and pragmatic solutions along the way are essential ingredients for constructive collaboration.

What does this mean in concrete terms? A few examples:

• “Tone makes the music”: treating each other with respect, addressing open points, taking problems seriously, and allowing co-creation.
• Giving editorial teams leeway in scheduling—within the overarching project timeline.
• Using tools flexibly (e.g., Excel instead of Miro if it works better).

Working with real text examples during the development of page types has clearly proven to be a crucial decision. With so many stakeholders, mature templates and distinct references are essential to ensure quality, consistency, and speed. The visualizations of the page types also play a central role. For people who think strongly in visual terms, writing in Word templates without a frontend preview is challenging. The visualizations at least serve as a general reference.

External experts can help smooth peak workloads and contribute an outside perspective to discussions. Beyond that, it is rewarding to see a shared team emerge across organizational boundaries—working together for the common goal.

…and in exactly this spirit, we are looking forward to the next, final process steps—and to an exciting year for the relaunch 🙂

The Bias Problem

The problem is bias. If you know that Response A comes from the expensive model and Response B from the cheaper one, you'll unconsciously read them differently. The idea behind our solution is borrowed from classic A/B testing: show two variants to evaluators without telling them which is which, and let the results speak. For RAG chatbots, the question isn't "which model is generally better?" It's "which configuration produces better answers for this specific knowledge base and these specific users?" That requires comparing pre-generated answers, not live model outputs.

Side by Side, Let's Evaluate

So we built Arena mode into the Admin UI. It works like this: you start by running your evaluation set against two different configurations. Maybe you're testing a new system prompt, or switching embedding models, or trying a different retrieval strategy. Each run produces answers for every question in the set. Then you create a comparison, selecting those two runs.

When an evaluator opens the comparison, they see one question at a time. Two answers, labeled A and B. No model names, no hints. The order is shuffled differently for each evaluator using a seeded randomization, so if Alice sees the Claude answer as "A" for question 3, Bob might see it as "B". This prevents evaluators from developing patterns like "A is always the better one."

For each answer, you rate it as Good, Neutral, or Bad. You can add a comment explaining why, which turns out to be incredibly valuable. The quantitative scores tell you which model wins, but the comments tell you why, and often reveal issues you wouldn't catch with automated evaluation.

More Feedback the Merrier

Multiple evaluators can rate the same comparison independently. Getting people involved is easy: share links generate a temporary API key, so you can send a URL to a colleague or a client and they can evaluate in a protected area without needing an admin account. They just enter their name and start rating.

Understand the Results

The results page shows a leaderboard: average score, win rate per model, and a breakdown per evaluator. That last part is where it gets interesting: it surfaces inter-annotator agreement, a standard measure of how much evaluators align in their ratings.

• High agreement: the quality difference is clear and you can act on the result with confidence.
• Low agreement: the two configurations are close enough that the choice may come down to other factors like cost or latency.

You can also drill into individual comments grouped by model, and export everything to Excel for reporting.

Calibrating AI with Human Truth

Building this was a good reminder that evaluation tooling is never "done." Christian recently wrote about using Claude Agent SDK to analyze chatbot answers automatically, which is the other side of the coin: scaling evaluation with AI. Arena mode complements that by providing the human ground truth that automated evaluation needs to calibrate against.

We're using Arena now whenever we make significant changes to a chatbot's configuration. The signal-to-noise ratio is much better than staring at spreadsheets of automated scores. The feature is available in the Admin UI for any organization that uses our evaluation sets.

The Next Steps of the Arena

We're considering adding support for more than two models in a single comparison, and possibly integrating the Arena ratings as ground truth labels for training better LLM-as-a-Judge prompts. For now, blind human evaluation with a simple Good/Neutral/Bad rating scheme gives us exactly what we need: honest answers about which configuration actually works better.

We already had an MCP server running on ZüriCityGPT and other LiipGPT deployments. Tools like knowledge base search, public transport timetables, and waste collection schedules were available to any MCP client, Claude Desktop, Cursor, or custom integrations. The tool definitions, schemas, and execution logic were all there. WebMCP just needed a bridge to bring them into the browser.

The implementation turned out to be surprisingly straightforward. When the page loads, a small script checks if navigator.modelContext exists. If it does, it fetches the available tools from our existing MCP endpoint using a standard JSON-RPC tools/list request and registers each one with navigator.modelContext.registerTool(). When an AI agent calls a tool, the execute handler sends a tools/call request back to the same endpoint. The entire client-side code is about 30 lines of vanilla JavaScript.

navigator.modelContext.registerTool({
  name: tool.name,
  description: tool.description,
  inputSchema: tool.inputSchema,
  execute: function(params) {
    return fetch(mcpUrl, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        jsonrpc: '2.0',
        method: 'tools/call',
        params: { name: tool.name, arguments: params }
      })
    }).then(r => r.json()).then(d => d.result);
  }
});

The beauty is that the tool set is dynamic and per site setup. ZüriCityGPT exposes search with a special mode for city council resolutions (Stadtratsbeschlüsse, see also StrbGPT), waste collection lookups via the OpenERZ API, and Swiss public transport departures. A different LiipGPT deployment would expose its own set of tools. The backend decides what's available, the browser just registers whatever comes back.

One thing worth noting: navigator.modelContext is behind a flag in Chrome Canary (chrome://flags/#enable-webmcp-testing) and not available in any stable browser yet. The script uses feature detection, so nothing happens in unsupported browsers.

To actually test it, you need Chrome Canary and the Model Context Tool Inspector extension (which requires a Gemini API key to do anything useful with the tools). But the registration itself works, and seeing "search", "get_waste_collection", and "get_timetable_info" show up in the inspector when visiting a chatbot page is a nice confirmation that everything clicks together.

Now, ZüriCityGPT is a page with essentially one big input field. It's already a chatbot. An AI agent visiting the site could just type into that field. Exposing structured tools on a page that is itself a tool feels a little redundant. But it does open up genuinely new possibilities. A browser agent could search the knowledge base, check the next tram departure, and look up waste collection dates in parallel, without ever touching the chat UI, and combine the results with data from other sites. The chatbot answers questions one at a time. WebMCP lets agents compose capabilities.

Is this useful today? Not really. No stable browser supports it, and the user base of Chrome Canary with experimental flags enabled is, let's say, select. Google and Microsoft are pushing it through the W3C, and formal browser support is expected by mid-to-late 2026. When that happens, any AI agent visiting ZüriCityGPT will automatically discover what it can do, no documentation reading and UI guessing required.

The interesting part is the convergence. We now have the same tool definitions serving three purposes: LangChain tools for the chatbot's own RAG pipeline, an MCP server for "traditional" AI clients, and WebMCP for browser agents. One set of schemas, three integration points. Adding a new tool to any LiipGPT site automatically makes it available everywhere.

If you want to try it yourself, visit zuericitygpt.ch with Chrome Canary, enable the WebMCP flag, and install the Model Context Tool Inspector extension. You'll see the three registered tools and can ask Gemini when your next paper collection is. Or just type the question into the chatbot, that still works too.