Loading ToolBench
Async QlikSense MCP Server with Playwright-based authentication for accessing QlikSense apps, tasks, and logs
QlikSense MCP server has significant definition quality gaps. While tool names follow verb_noun convention (list_apps, list_tasks, get_task_logs), the implementation suffers from minimal parameter descriptions, missing input schemas, and incomplete error handling guidance. All three tools have non-empty descriptions, but they are very short (24-52 chars) and lack context about prerequisites, return structure, and error recovery. The get_task_logs tool accepts a task_id parameter with a description present, but input schemas are not formally visible in the source code, they appear to be inferred from function signatures rather than explicitly registered. No output schemas are documented. Error handling returns generic exception strings without recovery guidance.
Haal logs op van specifieke QlikSense taak
Haal beschikbare QlikSense apps op
Haal beschikbare QlikSense taken op
No visible input schemas in tool registration. Tool parameters are inferred from Python function signatures (e.g., `async def get_task_logs(task_id: str)`) rather than explicitly declared in JSON Schema format. This violates MCP schema best practices and makes parameter constraints invisible to clients.
Tool descriptions are too short (<50 chars). 'Haal beschikbare QlikSense apps op' (24 chars) and 'Haal beschikbare QlikSense taken op' (34 chars) lack context about WHEN to use each tool, WHAT is returned, and WHY the agent would call them. Short descriptions prevent LLMs from understanding tool purpose and selection criteria.
No documented output schema. None of the three tools document what fields they return, their types, or structure. Clients cannot infer what data is available or plan downstream tool chains. For example, list_apps should document that it returns a list of objects with 'id' and 'name' fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 5 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Error responses are generic and non-actionable. All three tools catch exceptions and return `{"error": "Fout bij...: {str(e)}"}`. These provide no recovery guidance. Per the pattern, error responses must tell the LLM: 'User not found. Try search_users() with a partial name.' Instead, this server returns raw exception strings, leaving agents unable to self-correct.
Hardcoded XRF key '0123456789abcdef' is visible in qlik_client.py. While this is a standard placeholder, the implementation does not validate or document this security detail. Additionally, session_id acquisition involves browser automation with credentials, no documentation of how secrets are stored or rotated.
No input validation. The get_task_logs tool accepts any string as task_id with no validation against format, length, or allowed characters. If the parameter is a UUID or specific format, the description should state this. Currently: 'The ID of the task to retrieve logs for' provides no format guidance.