Provides tools for analyzing data-file lineage in Qlik Cloud tenants, including identifying unused columns and ghost files, enabling savings on capacity pricing.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@qlik-lineage-mcp list unused columns in the SalesData.qvd file"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A read-only Model Context Protocol (MCP) server that exposes data-file lineage analyses for Qlik Cloud tenants. Built especially for tenants on the capacity pricing model (daily peak GB), where dropping unused columns / ghost files yields direct savings.
Tool | What it answers |
| Given a data file (QVD or Parquet) and its space, which columns are not consumed by any app in the tenant? |
| Given a space, which data files are not consumed by any app — including transitive chains (file -> file -> app)? |
Both tools are read-only. They recommend, they never delete.
Related MCP server: SAP Datasphere MCP Server
# 1. Install deps with uv (or pip)
uv sync
# 2. Copy and fill the env file
copy .env.example .env
# edit QLIK_TENANT_URL and QLIK_API_KEY
# 3. Run the MCP server (stdio transport)
uv run qlik-lineage-mcpWire the server into Claude Desktop / Claude Code / VS Code:
{
"mcpServers": {
"qlik-lineage": {
"command": "uv",
"args": ["run", "qlik-lineage-mcp"],
"cwd": "C:/path/to/qlik-lineage-mcp"
}
}
}src/qlik_lineage_mcp/
├── server.py # FastMCP entry point — auto-registers everything in tools/
├── config.py # env-var loader (.env fallback)
├── qlik_client.py # all Qlik Cloud HTTP calls live here
├── models.py # format-agnostic Pydantic models (DataFile = QVD or Parquet)
└── tools/
├── __init__.py # auto-discovers and calls register(mcp) on each module
├── unused_columns.py
└── ghost_files.pyAdding a new tool: drop a file in tools/ that exports register(mcp: FastMCP).
server.py does not need to be edited.
unused_columns worksA 3-phase pipeline that uses Qlik's field-level lineage (no script parsing):
Enumerate columns — GET /lineage-graphs/nodes/{file_qri}?level=field
exposes every column of the target file as a node whose QRI starts with
the file QRI.
Find consumer apps — iterate every app in the tenant and read its
data/lineage. Apps whose discriminators include a lib://...{file_name}
LOAD reference are the consumers.
Detect renames — for each consumer app, fetch
GET /lineage-graphs/nodes/{app_qri}?level=field. Edges whose source is
a field of the target file map the original column to the alias used by
the app. Qlik decomposes composite expressions automatically, so
LOAD A_COD & '\' & A_LOJA AS KEY FROM file produces two edges
(A_COD->KEY, A_LOJA->KEY) — no script parser needed.
Cost: one file-side call + N data/lineage calls (one per app, also paid
by ghost_files) + M field-level lineage calls (one per consumer app).
Rename detection requires the consumer app to have been reloaded since field-level lineage was activated in the tenant. Apps that have not been reloaded show no edges in their field-level graph, so renames in those apps are invisible. The output lists which consumer apps could not be inspected so the verdict is auditable.
ghost_files walks every app's data/lineage and builds an app/file
graph, then runs a fixpoint to mark useful chains. Dependencies hidden
inside SUB / CALL / $(include) or dynamic file paths are missed.
Apps whose data/metadata cannot be fetched (permissions, errors) are
surfaced as a top-level metadata_unavailable_apps caveat — verdicts
are conditional on those apps being checkable.
Parquet support is implemented format-agnostically but until a real Parquet item-endpoint fixture is captured, surfacing of Parquet files is best-effort. The tools flag this in their output.
uv run pytestAll tests run against captured JSON fixtures in tests/fixtures/ —
no live tenant calls.
Return data files in a space that no app in the tenant consumes.
Args: space_name: Display name of the space to scan. Case-insensitive.
| Name | Required | Description | Default |
|---|---|---|---|
| space_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavioral traits. It does not mention read-only nature, side effects, permissions, or error handling (e.g., space not found).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, uses a structured Args format, and front-loads the main purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description should explain return values (e.g., list of file names). Current description only states what it returns but not the format or examples, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must add value. It states that space_name is the display name and case-insensitive, which helps. However, it does not specify expected format or constraints beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (return) and resource (data files) with a specific context (space with no app consumption). It implicitly distinguishes from sibling 'unused_columns', but could be more precise about 'data files'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'unused_columns'. The description only explains what it does without providing usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return columns of a data file that no app in the tenant consumes.
Args:
file_name: Data file name with extension (e.g. Sales.qvd).
Case-insensitive but extension must match.
space_name: Display name of the space the file lives in.
Case-insensitive.
lineage_activation_date: ISO 8601 date when field-level lineage
was activated in the tenant (e.g. "2025-06-01"). Consumer
apps last reloaded before this date have no edges in their
lineage graph and are marked as stale instead of being queried.
Omit to skip staleness detection.
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | Yes | ||
| space_name | Yes | ||
| lineage_activation_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses case-insensitivity and staleness detection behavior. However, it does not mention permissions, error handling, or side effects. The description adds some behavioral context beyond the schema but is not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, uses a clear docstring structure with bulleted Args, and front-loads the core purpose. One sentence could be slightly more direct, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameter semantics and some behavioral context, but lacks information about the output format (e.g., list of column names), pagination, or error cases. Given no output schema, this is a notable gap for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It explains each parameter's purpose, case-insensitivity, format (e.g., 'Sales.qvd'), and the optional lineage_activation_date's effect on staleness detection, adding significant meaning beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns columns of a data file that no app consumes, using specific verb-resource combination. This is distinct from the sibling tool 'ghost_files', which likely deals with unused files, not columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding unused columns and explains parameter constraints, but does not explicitly state when to use this tool versus the alternative 'ghost_files' or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0ghost_filesunused_columnsThe two tools have clearly distinct purposes: ghost_files identifies unused data files, while unused_columns identifies unused columns within a file. No overlap.
Both tool names follow a consistent snake_case verb_noun pattern (ghost_files, unused_columns), making them predictable.
With only 2 tools, the server is focused on a narrow domain (identifying unused resources). While minimal, the scope is appropriately scoped for its specific purpose.
The tools cover file-level and column-level unused resources, but missing capabilities such as listing spaces, retrieving lineage graphs, or identifying unused apps, which may be needed for full lineage analysis.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for AWS cloud spend: service breakdowns, anomalies, savings and forecasts.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/EngIcaro/qlik-lineage-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
