Qlik MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct Qlik Sense application component (data sources, dimensions, fields, measures, script, sheets, variables, sheet objects, or app listing). There is no functional overlap; an agent can easily select the correct tool for a specific task.
Naming Consistency4/5
All tool names follow a consistent pattern: 'handle_verb_noun' (e.g., handle_get_app_fields). The prefix 'handle_' is a code artifact that is not user-friendly, but the verb-noun structure after it is consistent and predictable.
Tool Count5/5
With 9 tools, the set is well-scoped for a read-only analysis server. Each tool covers a major aspect of Qlik Sense applications, and there is no redundancy or unnecessary tools.
Completeness4/5
The tool set covers the primary read operations for Qlik Sense applications: listing apps, retrieving script, data model components (fields, data sources), and analytics objects (dimensions, measures, sheets, variables, sheet objects). Minor gaps exist, such as lacking support for bookmarks or master items, but core workflows are covered.
Average 3.7/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions connecting, opening an app, retrieving objects, and returning JSON, but omits details like authentication requirements, read-only nature, performance implications, or error handling. The description lacks sufficient behavioral context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. The first sentence is slightly redundant ('MCP tool handler for retrieving...'), but overall it is efficient with minimal waste. Could be tightened by removing redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return value explanation is not required. However, the description does not cover nuances like container support or nested objects mentioned in the schema. It provides a high-level overview but lacks completeness regarding the complexity of the six parameters and their interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description in the input schema. The tool description does not add meaning beyond the schema, so it meets the baseline of 3. It neither significantly enhances nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves visualization objects from a sheet, with a clear verb ('retrieving') and resource ('visualization objects from a sheet'). It distinguishes itself from sibling tools, which handle app-level metadata (e.g., dimensions, measures) or list sheets, by focusing on objects within a specific sheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing sheet visualizations but does not explicitly state when to use this tool versus alternatives like handle_get_app_sheets for listing sheets or handle_get_app_measures for app-level metadata. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description minimally describes the retrieval process (connects, opens, creates, retrieves, returns) but does not disclose potential side effects, authentication needs, or performance implications. It is accurate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. The first sentence front-loads the purpose, and the second adds procedural context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately conveys the core action but omits mention of optional parameters that control response content (include_expression, include_tags). However, since the schema covers these, the description is minimally complete for the main task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with clear descriptions (app_id as GUID/name, include_expression and include_tags with defaults). The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieving' and the resource 'Qlik Sense measures', distinguishing it from sibling tools for other app resources like data sources, dimensions, fields, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention any context or exclusions. It only describes what the tool does, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It outlines the process (connect, open, retrieve, optionally analyze, return JSON) but lacks details on side effects, permissions, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the purpose and is reasonably concise, though slightly verbose with redundant phrasing like 'retrieving and analyzing' appearing twice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of a output schema, the description covers basic functionality but omits important contextual details such as authentication requirements, error conditions, or the structure of the returned JSON.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with each parameter having a description. The tool description adds minimal additional meaning beyond these schema descriptions, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves and optionally analyzes the Qlik Sense application script, distinguishing it from sibling tools that handle other aspects like data sources, dimensions, or sheets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for script retrieval and analysis, but does not explicitly state when to use this tool versus alternatives, nor provides 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it retrieves a list. It does not mention any side effects, authentication, performance, or additional behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, clear and to the point. It could be slightly more concise but has no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no parameters and an output schema, the description is adequate but lacks details like pagination, ordering, or note about potential large results. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description correctly indicates no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all Qlik Sense applications with names and IDs, using a specific verb and resource. It distinguishes from sibling tools which target specific application details (e.g., fields, sheets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use as an entry point to get an app overview before using sibling tools, but lacks explicit when-to-use or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral traits. It mentions connecting to a server and creating session objects but does not specify if the operation is read-only, required permissions, rate limits, or potential side effects. The description is acceptable but lacks key behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, efficiently summarizing the tool's purpose and workflow. The first sentence is slightly redundant ('MCP tool handler for...') but not overly verbose. Well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown) and full schema descriptions for parameters, the description provides sufficient context for an AI agent to understand the tool's purpose and mechanism. However, it could mention that the tool does not modify data and that the boolean parameters filter results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters. The tool description does not add additional meaning beyond what is already in the schema (e.g., it does not elaborate on the boolean toggles or the app_id format). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves Qlik Sense fields and table information, specifying the exact actions (connects, opens app, creates FieldList, retrieves metadata, returns JSON). It distinguishes from sibling tools which focus on other app components like dimensions or measures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives. It only describes functionality, leaving usage context implied (e.g., when field and table info is needed). No exclusion criteria or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool is read-only (no destructive hints) and describes the server connection and session creation. However, it omits details like authentication requirements, rate limits, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that efficiently convey the tool's purpose and process. The first sentence is somewhat technical ('MCP tool handler') but still clear. It is front-loaded and avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required parameter, four optional booleans) and the presence of an output schema, the description adequately covers the behavior. It explains the retrieval mechanism and return format. It does not state pagination or limits, but the booleans handle filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions (e.g., app_id as 'GUID format or app name', booleans like 'Include variable definitions/expressions'). The tool description does not add extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Qlik Sense variables with specific steps ('connects to a Qlik Sense server, opens the specified application, creates a VariableList session object'). The purpose is distinct from sibling tools targeting other entities like fields, measures, sheets, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving variables but provides no explicit guidance on when to prefer this tool over siblings. It does not mention alternatives or exclusion criteria, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It covers connecting to server, opening app, retrieving dimensions, and returning JSON. However, it does not mention authentication needs, rate limits, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and contains no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the simple retrieval nature, the description adequately explains the tool's purpose. It lacks mention of error handling or performance, but these are not critical for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The tool description adds no extra meaning beyond the schema, so a baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves dimensions from a Qlik Sense application with metadata, distinguishing it from sibling tools like fields, measures, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It describes what the tool does but does not explicitly state when to use it versus alternatives like get_app_fields or get_app_measures. Usage is implied by the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It describes the steps (connects, opens app, creates SheetList, retrieves metadata) but does not disclose potential side effects, authentication requirements, or rate limits. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a few sentences long, front-loaded with the purpose. It could be slightly more concise (e.g., 'Retrieve all sheets from a Qlik Sense app' instead of the longer first sentence). No waste, but some redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description need not explain return values. It covers the process adequately. However, it lacks usage guidelines or caveats, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description adds minimal value beyond the schema's param descriptions, e.g., it repeats 'retrieves all sheet metadata'. No additional clarification on format or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Qlik Sense sheets, with specific verb+resource. The sibling tools (e.g., handle_get_app_dimensions, handle_get_app_fields) indicate distinct resources, making this one unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool connects to a server and retrieves sheets, but does not explicitly tell when to use this tool versus alternatives like handle_get_sheet_objects. However, the context of sibling tools and the name imply it is for listing all sheets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses it connects to a server, opens an app, retrieves lineage, and returns categorized results. It does not mention side effects, authentication requirements, or performance considerations, but as a read operation the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and contains no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate parameter count (5), required fields (1), and presence of an output schema, the description provides sufficient context. It mentions 'categorized results' which is appropriate since the output schema presumably details categories. The tool's complexity is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds minimal value beyond what the input schema already provides. The description reiterates 'lineage information to identify all data sources' but does not elaborate on parameter usage beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieves'), resource ('data sources from Qlik Sense application'), and scope ('LOAD and STORE statements'). It distinguishes from siblings (e.g., handle_get_app_dimensions, handle_get_app_fields) by focusing specifically on data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to identify data sources, but does not explicitly state when not to use it or compare to alternatives. However, sibling tool names provide enough context that this tool is for data sources, not other application components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![qlik-mcp-server MCP server](https://glama.ai/mcp/servers/arthurfantaci/qlik-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/arthurfantaci/qlik-mcp-server)

Score Badge

Copy to your README.md:

[![qlik-mcp-server MCP server](https://glama.ai/mcp/servers/arthurfantaci/qlik-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/arthurfantaci/qlik-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/arthurfantaci/qlik-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server