qlik-cloud-admin

by ryailabs

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

qlikcloud_get

Fetch data from Qlik Cloud REST API, including app metadata, lineage, and audits. Use for read-only operations.

Instructions

Read anything from Qlik Cloud over REST: the only read tool in this server.

This is how you fetch an app's data model and field metadata, its load script and lineage, glossary terms and definitions, spaces, users, items, datasets, data products, reloads and audits — any GET endpoint on qlik.dev. Reach for it whenever you need to look something up, list, search, count or profile.

Named so a client that loads tool schemas on demand can find it: this tool is the retrieval, read, fetch, list, search, describe and inspect capability. If it is not in your visible tool list it is deferred, not absent — call it by name.

Runs as the signed-in Qlik Cloud user, with exactly their permissions. Results are already filtered to what that user can see, so a short list is their view, not an error.

Use this only when no tool in the official Qlik MCP Server covers the operation. Prefer Qlik MCP tools for analytics operations such as opening apps, searching fields, listing sheets, or reading app content.

Qlik list endpoints return one page at a time. Set fetch_all=True when the user asks for all of something (all spaces, all users, every app in a space) or asks for a count. Leave it off for lookups and single-record reads. When a cap is reached the result says so via "truncated" and "truncatedReason" — do not present a truncated list as complete.

Args: path: API path, e.g. /api/v1/spaces. See https://qlik.dev/apis/rest/. The older qlik-cli form (v1/spaces) is also accepted. query_params: Optional query string, e.g. "limit=10&type=shared" fetch_all: Follow pagination links and merge every page. max_pages: Maximum pages to fetch when fetch_all is set (ceiling 100).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	Yes
`fetch_all`	No
`max_pages`	No
`query_params`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Sep 8, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full transparency burden and does so thoroughly: it states read-only behavior, permission-based filtering, one-page-at-a-time pagination, and the truncation indicator behavior. It also notes the user context under which requests run.

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 well structured with clear paragraphs and an Args section, but it includes some redundant meta-commentary about naming and repeated emphasis on being the only read tool. It remains focused and readable, though slightly longer than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the API surface, argument usage, pagination behavior, truncation reporting, and permissions context. Since an output schema exists, not detailing every return field is acceptable; the description provides enough context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides no parameter descriptions, but the description compensates by explaining path formats with an example, query_params with a concrete example, fetch_all semantics, and the max_pages ceiling. Each parameter gains meaning beyond the raw schema.

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 reads anything from Qlik Cloud over REST and is the only read tool in this server. It explicitly differentiates from sibling tools like qlikcloud_delete and qlikcloud_login by scope and action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit guidance on when to use this tool versus the official Qlik MCP Server, and explains when to set fetch_all for 'all' queries or counts versus single-record lookups. This leaves no ambiguity about tool selection or pagination use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server