DEV Community: Adam Wilson

How to Set Up the Qlik MCP Server with Claude.ai and Actually Do Useful Stuff With It

Adam Wilson — Thu, 26 Feb 2026 13:00:00 +0000

I've been in data long enough to remember when "self-service analytics" meant you could run your own queries in SQL Management Studio instead of asking someone else to do it for you, but this is actually different. The Qlik MCP (Model Context Protocol) server with Claude is the kind of thing that makes you sit back and think "Okay, maybe we are living in the future". Then you immediately try to ask it something and get confused about OAuth scopes, and you're firmly back in the present.

Don't worry. I've done the confused part so you don't have to. Let's dig in.

First, What Even Is MCP?

MCP stands for Model Context Protocol. It's an open standard created by Anthropic that lets AI assistants like Claude securely connect to external tools, data sources, and services. Think of it as a universal adapter the kind that actually works, unlike those cheap travel adapters that melt your laptop charger.

In plain terms: MCP is what allows Claude to start actually talking to your systems. Instead of you copying data out of Qlik and pasting it into an AI chat window (we've all done it, no judgment), Claude can go directly to the source.

Qlik launched its official MCP server to in February 2026, enabling third-party assistants including Anthropic Claude to securely access Qlik's analytical capabilities and trusted data products. So this isn't a hacky workaround it's built for production.

The Architecture (Without the Architecture Diagram Nobody Reads)

Here's what's happening under the hood:

Your Qlik Cloud tenant exposes an MCP endpoint at <your-tenant-url>/api/ai/mcp. Claude.ai (or Claude Desktop) connects to that endpoint via OAuth. Once authenticated, Claude can call a set of tools exposed by the Qlik MCP server things like searching for apps, querying data, making selections, building charts, managing spaces, and a whole lot more.

The key thing Qlik is emphasising here is governance. An assistant can request analysis based on Qlik-managed measures rather than generating an answer from copied data or a user-provided spreadsheet.

In other words, the numbers Claude gives you are your numbers, calculated by Qlik, using your business definitions. Not hallucinated. Revolutionary concept, I know.

Setting Up the Qlik MCP Server with Claude.ai

Right, let's get our hands dirty. I have only tried the official Qlik Cloud way, although if you are brave enough you can go down the self-hosted open-source way (more control, more configuration, more opportunities to question your life choices).

Step 1: Enable AI Features on Your Tenant

Before anything else, your Qlik Cloud tenant needs to have AI features enabled and you will need to enable cross-region data processing. this can be found in you administration settings at the bottom of the page.

Step 2: Allow users access to the Qlik MCP server

This is done by user role permissions, setup a new role if one has not already been created and under Features and actions > Agentic AI set MCP to Allowed.

Users can then be granted this role giving them access to Qlik MCP server

There's also a default shared Client ID (76d3f46e87655a50424bec7e0f0bb1e2) that Qlik provides for Claude specifically. Depending on your tenant's security setup, you can use either this or your own custom one.

Step 3: Connect Claude.ai to the Qlik MCP Server

Now the fun part. In Claude.ai:

Open Settings
Navigate to Connectors
Click Add custom connector
Give it a name - something professional like "Qlik MCP"
For the Remote MCP Server URL, enter: <your-tenant-url>/api/ai/mcp
Under Advanced settings, enter your OAuth Client ID here is the default shared Client ID (76d3f46e87655a50424bec7e0f0bb1e2) that Qlik provides for Claude specifically.
Leave the OAuth Client Secret field empty
Click Connect
Sign into your Qlik Cloud tenant when prompted
Click Approve
In your Setting > Connectors you will now see your newly created custom connector, click on Configure and set all Tool permissions to Always allow

And that's it. You're connected. Claude can now see your Qlik world.

So What Can You Actually DO With It?

Now for the part everyone actually cares about. Here's just some of the things that I have played around with while testing.

Discover and Navigate Your Qlik Environment

You can ask Claude to list and navigate everything in your Qlik Cloud tenant. Apps, spaces, sheets, datasets all of it becomes conversational.

“Show me all the apps in the Sales space”
“What sheets does the Revenue Dashboard have?”
”Find any app related to supply chain”

This sounds simple but it's genuinely powerful when you're working in a large tenant, instead of looking for that one app someone built two years ago and named something deeply unhelpful, you just ask.

Query and Analyse Data From Your Apps

This is the headline feature. Claude can reach into your Qlik apps and actually compute against your data using the Qlik associative engine.

“What were total sales by region for Q4 2025?”
”Show me the top 10 customers by revenue”
”What's our average order value this month vs last month?”

The critical thing here and it's worth saying again is that these calculations are done by Qlik's engine, not guessed by Claude. The associative model, your master measures, your business logic all of it stays intact. Claude is the natural language interface; Qlik is doing the calculations.

Apply Filters and Selections Conversationally

One of my favourite features. You can apply selections to your data through conversation, exactly as you would clicking in a Qlik sheet.

“Filter to only show data from the UK”
”Select Q1 and Q2 only”
“Clear all selections and start fresh”

You can even use advanced patterns like range queries: "Show me only customers with revenue greater than £100,000". Claude translates that into the right Qlik selection syntax so you don't have to think about set analysis expressions. (Though if you're a Qlik nerd who enjoys set analysis, nothing is stopping you from writing your own.)

Create Charts and Visualisations

Yes, Claude can actually build charts inside your Qlik apps. Not mock-ups. Not suggestions. Actual charts on actual sheets.

“Add a bar chart to my Sales Overview sheet showing revenue by product category”
”Create a KPI showing total headcount”
”Build a line chart of monthly revenue with a moving average”

It supports bar charts, line charts, pie charts, scatter plots, KPIs, tables, treemaps, heatmaps, combo charts, and pivot tables.

What to Watch Out For

A few things worth knowing before you start using this in anger:

Capacity limits are real. A tenant's Qlik MCP server can have a maximum of 20 concurrent application sessions loaded into memory at one time, and there is a maximum of 300 MCP tool calls per user per minute through the Qlik API gateway. For most use cases this is fine. For power users hammering complex queries all day, plan accordingly.

Sessions time out. OAuth sessions don't last forever. If your session is disconnected, access the LLM client's settings to establish a new session. This is slightly annoying but takes 30 seconds to fix.

Governance conversations still need to happen. The data is governed by Qlik, but you're still sending queries and results through Claude. Make sure your data governance and security teams know what data you're putting into this workflow especially for anything regulated or sensitive.

Monthly question quotas. Depending on your subscription, you have a monthly quota of questions. Questions do not carry over between months. When you hit your limit, users can no longer ask questions until the next month.

Quick Reference: Useful Things to Ask Claude Once You're Connected

Here's a cheat sheet of prompts to get you going:

"List all Qlik apps I have access to"
"What sheets are in the [App Name] app?"
"Show me total revenue by country for 2025"
"Filter to just Q4 and show me the top 5 products"
"Clear all my current selections"
"Add a bar chart to [Sheet Name] showing [measure] by [dimension]"
"Search for any dataset related to customers"
"Show me the lineage for [Dataset Name]"
"Find the glossary definition for [Term]"
"What's in the [Space Name] space?"

Wrapping Up

The Qlik MCP server with Claude.ai is genuinely one of the more exciting developments in the BI space in a while and I don't say that lightly, given that I have to get excited about data for a living.

The setup, as we've covered, isn't particularly painful. The native Claude.ai integration is a few clicks and an OAuth dance. The open-source path is a bit more involved but gives you flexibility. Either way, once you're connected, you've got a surprisingly capable interface to one of the most mature analytics platforms out there.

And if it turns out that your executives really do start just asking Claude questions about your data instead of scheduling a meeting to ask you to make a chart well, look on the bright side. You can spend that freed-up time building something even better. Or finally understanding what your own set analysis expressions actually do.

Either way, have fun with it. This stuff is cool.

Have questions about the setup? Found something broken? Discovered a use case I haven't mentioned? Drop a comment below or, fittingly, just ask Claude about it.

Build Measures Faster: Using DAX Query View in Microsoft Power BI

Adam Wilson — Tue, 24 Feb 2026 12:00:00 +0000

If you’ve spent any serious time building models in Microsoft Power BI, you’ll remember the old ritual.

Create measure.

Hit Enter

Wait

Watch the little spinner

Question your life choices

Repeat

Over and over and over again

The Old Way: Measure-by-Measure Misery

Creating measures used to feel… heavier than it should.

You’d:

Right-click a table
Click New Measure
Write your DAX
Press Enter
Wait for the model to update
Hope nothing broke
Repeat 47 more times

On small models? Fine.

On enterprise models every single enter key press triggered a model validation and recalculation. And when you’re building a full KPI layer: Revenue, Revenue YTD, Revenue LY, Variance, Variance %, Rolling 12, etc. that lag adds up fast.

It wasn’t just slow. It broke your flow.

Enter: DAX Query View (Where Has This Been All My Life?)

Somewhere along the way (and yes, I might be late to this party), I properly started using DAX Query View.

And suddenly…

You can write multiple measures in one go

No waiting after each one

No constant model refresh after every Enter

Just clean, uninterrupted DAX writing

Why This Is Such a Big Deal

When you use DAX Query View, you can define measures in batches.

Instead of:

Revenue = SUM(Sales[Amount])

wait

Revenue YTD = TOTALYTD([Revenue], 'Date'[Date])

wait

Revenue LY = CALCULATE([Revenue], SAMEPERIODLASTYEAR('Date'[Date]))

wait

You can define them together in a structured block and apply changes in one operation.

DEFINE
    MEASURE 'Measure Table'[Revenue] = SUM(Sales[Amount])
    MEASURE 'Measure Table'[Revenue YTD] = TOTALYTD([Revenue], 'Date'[Date])
    MEASURE 'Measure Table'[Revenue LY] = CALCULATE([Revenue], SAMEPERIODLASTYEAR ('Date'[Date]))
    MEASURE 'Measure Table'[Revenue Variance] = [Revenue] - [Revenue LY]
    MEASURE 'Measure Table'[Revenue Variance %] = DIVIDE([Revenue Variance], [Revenue LY])

That means:

Faster measure development
Better logical grouping of related calculations
Easier refactoring
Fewer interruptions to your concentration

When you're building out a semantic layer especially on larger models this saves a ridiculous amount of time.

The Real Productivity Gain

The biggest improvement isn’t just speed. It’s flow.

You can:

Draft an entire KPI framework in one sitting
Create base measures and derived measures together
Spot naming inconsistencies immediately
Structure things more cleanly

It encourages you to think architecturally instead of tactically.

Instead of reacting to model updates after every line, you design the measure layer properly and then commit it.

“Am I Late to This?”

Honestly? Probably.

But I only properly embraced this in my latest project, and I’m not exaggerating when I say it changed how I build models.

Sometimes features land quietly, and you don’t realise how much friction they remove until you use them intentionally.

If You’re Still Doing It the Old Way…

Stop torturing yourself.

Open DAX Query View.

Batch define your measures.

Grouping Measures in a Field Parameter

Adam Wilson — Mon, 23 Feb 2026 13:00:00 +0000

Field parameters are one of those Power BI features that feel like witchcraft the first time you use them. Switch between measures dynamically? No calculated columns? No DAX spaghetti? Sold.

Then the report grows. And grows. And suddenly your elegant little slicer looks like the terms and conditions scroll on a software licence agreement. Somewhere around measure number fifteen, your users quietly give up and just pick whatever's at the top.

This week, a customer hit exactly that wall.

The Setup

They had a field parameter doing its thing letting users switch between a bunch of measures in a single visual. Classic pattern, works great, 10/10 would recommend. It looked something like this:

Measures List = {
    ("Orders",    NAMEOF('Measure Table'[Orders]),    0),
    ("Quantity",  NAMEOF('Measure Table'[Quantity]),  1),
    ("Total Due", NAMEOF('Measure Table'[Total Due]), 2)
}

Clean. Tidy. Then the business had thoughts. More measures got added. Then a few more. The slicer became a liability.

What they actually wanted was pretty reasonable:

Orders and Quantity grouped under Sales
Total Due under Totals
Slicers and navigation built around those groups instead of one giant undifferentiated list

Simple enough request. And then came the question that always sounds reasonable until you dig into it:

"Can we just add another column to group the measures?"

Oh, if only.

The Catch

Here's where field parameters show their quirks. Under the hood, they're built using a static table constructor those curly braces with tuples. And static means static. You can't sneak a column in afterwards. You can't make it dynamic. Every column that's ever going to exist needs to be defined right there, upfront, at creation time.

So if you've got an existing parameter table and you try to bolt a grouping column onto it after the fact? Power BI will politely decline. Less politely if you've been staring at it for an hour.

The good news: the fix is clean, it's not a hack, and it doesn't break your existing visuals.

The Fix

Instead of trying to add a column later, you include the grouping value inside the tuples when defining the parameter. It's a fourth value, sitting right there alongside the display name, field reference, and sort order:

Measures List =
{
    ("Orders",    NAMEOF('Measure Table'[Orders]),    0, "Sales"),
    ("Quantity",  NAMEOF('Measure Table'[Quantity]),  1, "Sales"),
    ("Total Due", NAMEOF('Measure Table'[Total Due]), 2, "Totals")
}

After that, head into the Model view, find your parameter table, and rename that fourth column to something sensible — Measures List Group works nicely. Once you've done that, your table looks like this:

Measures List	Measures List Fields	Measures List Order	Measures List Group
Orders	'Measure Table'[Orders]	0	Sales
Quantity	'Measure Table'[Quantity]	1	Sales
Total Due	'Measure Table'[Total Due]	2	Totals

Which is exactly what the customer wanted. Job done, everyone goes home happy.

Why Bother? (Beyond "The Slicer Was Annoying")

Once that Group column exists, you've actually unlocked a bunch of useful patterns:

Slicer on the Group column users pick a category first, then drill into specific measures. Much cleaner UX than scrolling a wall of options.
Conditional navigation show/hide visuals or sections based on selected group.
Better scalability you can keep adding measures without the report turning into a maze, because they automatically slot into their groups.
Sort order still works the Order column keeps everything tidy within each group.

The real problem this solves isn't the slicer. It's the fact that a report that's annoying to use is a report that doesn't get used. Grouping is just the mechanism; usability is the actual goal.

The Bit Worth Remembering

Field parameters are explicit by design what you define is what you get, and you can't quietly patch things in later. That's fine once you know it. The practical takeaway is this: if you think you might want grouping, sorting, or categories down the line, build those columns into the parameter now. Even if you're not using them yet. Future you will be very smug about it.

And if you've already got a sprawling parameter table that needs this treatment? The pattern works as a retrofit define the group values, rename the column, build your slicers. Existing visuals that reference the parameter won't care. They're just looking at the fields they've always looked at.

Using Qlik Regex to Organise Messy Comment Fields

Adam Wilson — Mon, 16 Feb 2026 17:06:37 +0000

Free-text fields are both a blessing and a curse.

They give users flexibility, but from a reporting point of view they’re often messy, inconsistent, and hard to work with. In this case, a customer had a Comments field where users manually typed information, but inside that text was a specific code they needed for reporting.

The requirement was simple on paper:

Extract a code from a free-text comments field.

In reality… not so simple

Let’s walk through how regular expressions in Qlik can solve this cleanly and reliably.

The Problem

The source field looked something like this:

"Breakdown reported – REF12345 vehicle unavailable"
"Job completed ABC 67890 no further action"
"Awaiting parts – no reference provided"

The rules for the code were consistent:

3 uppercase letters
Optional space
5 digits

Examples of valid codes:

ABC12345
ABC 12345

The challenge:

The code could appear anywhere in the text
Some rows didn’t contain a code at all
We needed a clean output suitable for filtering and analysis

Why Regular Expressions?

You could try to solve this with string functions like Mid(), Left(), or Index(), but that approach quickly falls apart when:

The position of the code varies
The spacing isn’t consistent
The text contains lots of noise

Regular expressions (regex) are designed for exactly this kind of pattern matching.

The Solution

This is the expression I used:

Coalesce(
    Replace(
        ExtractRegEx(
            [Comments],
            '[A-Z]{3}\s?\d{5}',
            1
        ),
        ' ',
        ''
    ),
    'NOT FOUND'
)

Let’s break it down.

Step 1: Extract the Code with `ExtractRegEx`

ExtractRegEx(
    [Comments],
    '[A-Z]{3}\s?\d{5}',
    1
)

The regex pattern:

[A-Z]{3} → exactly 3 uppercase letters
\s? → optional space
\d{5} → exactly 5 digits

This tells Qlik:

“Find me the first occurrence of three letters followed by five numbers, with or without a space.”

If no match is found, ExtractRegEx() returns NULL.

Step 2: Remove the Space (If It Exists)

Replace(…, ' ', '')

If the original text contained ABC 12345, this step converts it to:

ABC12345

This ensures the output is always consistent, which is crucial for joins, filters, and comparisons later on.

Step 3: Handle Missing Codes with `Coalesce`

Coalesce(…, 'NOT FOUND')

When no matching code exists, ExtractRegEx() returns NULL. Wrapping everything in Coalesce() lets us replace those NULLs with something meaningful:

NOT FOUND

This makes the result:

Easier to understand for users
Easier to filter in the app
Safer for downstream logic

Final Result

Comments Text	Extracted Code
Breakdown reported – REF12345 vehicle unavailable	REF12345
Job completed ABC 67890 no further action	ABC67890
Awaiting parts – no reference provided	NOT FOUND

Clean, consistent, and analysis-ready

Why This Matters

Using regex in Qlik allows you to:

Extract structured data from unstructured text
Reduce manual data cleansing
Build more reliable KPIs and dimensions
Handle real-world, messy user input gracefully

If you work with comments, notes, descriptions, or reference fields, regex is one of the most powerful tools you can add to your Qlik toolbox.

Developing in Production (Yes, Really)

Adam Wilson — Mon, 09 Feb 2026 14:06:04 +0000

There’s a version of data work that exists in documentation, architecture diagrams, and conference talks. It has clean environments, clear requirements, and a sensible deployment process. And then there’s the version I keep encountering, the one where production is already live, the data refresh is scheduled, and the question is no longer “should we test this?” but “how noticeable will this be if it breaks?”

This blog exists because most of what I’ve learned about data, BI, cloud platforms, modelling, and analytics didn’t come from carefully staged environments. It came from doing real work on real systems, often under time pressure, sometimes with incomplete information, and occasionally while hoping no one was actively looking at the dashboard I just changed.

Developing in production isn’t something I aim for. It’s something that happens. Deadlines arrive. Data changes shape. Requirements evolve mid-refresh. The “proper” way gives way to the necessary way, and suddenly production becomes the place where the lesson actually sticks. Not because it’s ideal but because the consequences are real.

I’m starting this blog to document those lessons as they happen. Not the polished, best-practice version you’d present in hindsight, but the version you learn while fixing something that worked yesterday and inexplicably doesn’t today. The moments where a small change reveals a much bigger misunderstanding. The quiet wins. The loud mistakes. The “oh, that’s how that actually works” realisations.

This isn’t a guide to doing things perfectly. It’s a record of learning by building, breaking, and fixing. Sometimes carefully. Sometimes directly on production. Always with the goal of understanding things a little better next time.

If you’ve ever:

trusted a dashboard and immediately regretted it
learned more from a production issue than a week of documentation
made a “small change” that was, in fact, not small

then you already understand the premise.

Future posts will be practical, specific, and occasionally confessional, covering data modelling, BI tools, cloud platforms, and whatever else I happen to be learning the hard way. If nothing else, this will serve as a reminder to my future self of what not to do again.

DEV Community: Adam Wilson

How to Set Up the Qlik MCP Server with Claude.ai and Actually Do Useful Stuff With It

First, What Even Is MCP?

The Architecture (Without the Architecture Diagram Nobody Reads)

Setting Up the Qlik MCP Server with Claude.ai

Step 1: Enable AI Features on Your Tenant

Step 2: Allow users access to the Qlik MCP server

Step 3: Connect Claude.ai to the Qlik MCP Server

So What Can You Actually DO With It?

Discover and Navigate Your Qlik Environment

Query and Analyse Data From Your Apps

Apply Filters and Selections Conversationally

Create Charts and Visualisations

What to Watch Out For

Quick Reference: Useful Things to Ask Claude Once You're Connected

Wrapping Up

Build Measures Faster: Using DAX Query View in Microsoft Power BI

The Old Way: Measure-by-Measure Misery

Enter: DAX Query View (Where Has This Been All My Life?)

Why This Is Such a Big Deal

The Real Productivity Gain

“Am I Late to This?”

If You’re Still Doing It the Old Way…

Grouping Measures in a Field Parameter

The Setup

The Catch

The Fix

Why Bother? (Beyond "The Slicer Was Annoying")

The Bit Worth Remembering

Using Qlik Regex to Organise Messy Comment Fields

The Problem

Why Regular Expressions?

The Solution

Step 1: Extract the Code with ExtractRegEx

The regex pattern:

Step 2: Remove the Space (If It Exists)

Step 3: Handle Missing Codes with Coalesce

Final Result

Why This Matters

Developing in Production (Yes, Really)

Step 1: Extract the Code with `ExtractRegEx`

Step 3: Handle Missing Codes with `Coalesce`