Super Artifacts

Aggregate what was collected

super_data_query

Read-only

Numbers over what was collected, never rows (rows are super_data). Aggregate measures across the datasets in scope; datasets combine on the same measure in one base unit, results in the declared unit. Names come from the catalog; an unknown one errors with near misses. The answer has one row per group_by key (or one row) with a column per measure and compute, the datasets used and any skipped, and truncated when limit cut it. Or send distributions for one artifact: counts, per-version rates and per-field distributions (free text: answer rate and length only). A call with neither is invalid_query.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "super_data_query"
  }
}

Input Schema

Name	Required	Description
`agg`	No
`limit`	No
`scope`	No	The union of the forms given.
`since`	No	ISO-8601 instant or window (7d, 24h).
`until`	No
`filter`	No	ANDed 'field op value' clauses: 'reps >= 5', 'day in mon,tue', 'note is set'. Ops: = != > >= < <= in. Catalog fields only.
`compute`	No	Derived columns, in order; operands name a measure or an earlier `as`.
`group_by`	No	One of dataset, day, week, month, visitor, or "field:{name}".
`measures`	No	Catalog measure names, not field names.
`distributions`	No	One artifact's per-field distributions instead of a scoped query.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 27, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With annotations already declaring read-only, non-destructive, closed-world behavior, the description adds substantial operational context: unknown catalog names error with near misses, results include skipped datasets and `truncated` when `limit` cuts output, and distributions have specific free-text limitations. These details go well beyond the annotations.

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 dense but front-loaded, opening with the core distinction from row tools and then covering aggregation behavior, output shape, alternate mode, and error case. Every sentence carries useful information for a complex 10-parameter tool.

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?

There is no output schema, so the description appropriately explains the result shape: one row per `group_by` key or one row, columns per measure and `compute`, datasets used/skipped, and `truncated`. It is nearly complete, though it omits details about `agg` operation selection and time-window parameters.

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?

Schema coverage is 70%, and the description adds meaning for several core parameters: `measures` are catalog names, `group_by` controls output rows, `compute` creates derived columns, `limit` can truncate results, and `distributions` has a distinct artifact-level mode. It does not explain the `agg` operations or the `since`/`until` time window semantics, leaving some parameter meaning to the 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 states a specific operation, aggregating `measures` across datasets in `scope`, and explicitly distinguishes it from row retrieval: 'never rows (rows are super_data)'. This lets an agent separate it from the sibling `super_data` without inspecting schemas.

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 explicitly routes row-level needs to `super_data` and defines the alternative mode: 'Or send `distributions` for one artifact'. It also states that a call with neither mode is `invalid_query`, giving clear when-to-use and 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.

All Super Artifacts tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?