Loading ToolBench
The server defines 12 tools with explicit FastMCP registration and consistent naming patterns. All tools have descriptions and documented input parameters with types. However, output schemas are not documented, error handling guidance is minimal, and several tools operate at a very high abstraction level (generic 'call any endpoint' patterns) that reduce clarity. Parameter descriptions are present but often terse (avg ~40-60 chars). The server prioritizes API coverage over usability, tools like superset_call_endpoint and superset_raw_api essentially expose the underlying API with minimal abstraction, which is pragmatic for extensibility but creates ambiguity for LLM selection. No evidence of output schema documentation, pagination details in responses, or recovery guidance in error cases.
Call any Superset endpoint by operation_id from the OpenAPI spec.
Convenience tool for creating a chart/slice.
Convenience tool for creating a dashboard.
Create resource in Superset. Payload must match Superset API schema.
Delete a resource by id.
Execute SQL Lab query in Superset.
Output schemas not documented. No tool description or docstring specifies what fields are returned, what structure the response has, or what the LLM should expect. This forces LLMs to guess at downstream field names and types, increasing errors.
Error handling provides no recovery guidance. Parameter descriptions (e.g., 'JSON payload for POST/PUT/PATCH requests') lack format constraints, examples, or actionable error messages. An LLM passing malformed JSON or invalid enums gets a bare API error with no guidance on how to fix it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Get details of a single resource by id.
Check Superset API health endpoint.
List Superset OpenAPI operations (operation_id + method + path).
List dashboards/charts/datasets/databases etc.
Escape hatch for custom calls; path must start with '/api/v1/' or '/swagger/'.
Update existing resource via PATCH (default) or PUT.
Generic 'escape hatch' tools (superset_call_endpoint, superset_raw_api) shift API discovery and validation burden entirely to the LLM. These tools accept free-form operation_id, method, path, and payload with minimal validation. While pragmatic for coverage, they make it harder for LLMs to know which operation to call, what parameters are required, and what will happen. Parameter 'payload' accepts any object with no schema guidance.
Parameter descriptions are terse and lack format/constraint details. E.g., 'JSON string of visualization parameters' (superset_create_chart) does not tell the LLM what keys the JSON must contain, what types values should be, or what happens if the JSON is invalid. Parameter 'path_params', 'query_params', 'payload' in superset_call_endpoint are all generic objects with zero schema guidance.
No enum constraints on resource type parameters. superset_list_resources, superset_get_resource, superset_create_resource, superset_update_resource, superset_delete_resource all take a 'resource' parameter described as 'Resource type: dashboard, chart, dataset, database, saved_query, or tag', but no enum in the JSON Schema. LLMs can hallucinate invalid types like 'report' or 'datasource'.
No pagination guidance in tool descriptions. superset_list_resources accepts page and page_size but the description does not mention total count, next_cursor, or how many total items exist. An LLM listing resources does not know if results are truncated or if it has seen everything.
Destructive operations lack confirmation or dry-run support. superset_delete_resource and superset_update_resource can permanently modify or erase data, but no confirmation flow, dry-run option, or warning is documented. An agent mistake could cascade into data loss.
Tool naming uses generic, vague verbs for high-level operations. 'superset_call_endpoint' and 'superset_raw_api' are not descriptive of what they do, they are escape hatches that bypass higher-level abstractions. An LLM must read the full description and understand OpenAPI internals to use them correctly. Better: 'execute_openapi_operation' or 'invoke_api_method' with clearer intent.