Super Artifacts

Read what visitors submitted

super_data

Read-only

The rows visitors submitted to your artifacts, newest first, with each version's field schema; paged by cursor. Address exactly one: artifact; dataset (a catalog key; one shared by several artifacts is ambiguous_dataset); or collection, the gallery grouping label set at publish, not a content collection (≤20 artifacts over one window, kept per artifact, no filter). Entries of a content collection are super_entries; totals and averages are a query, not a read.

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"
  }
}

Input Schema

Name	Required	Description
`sort`	No	By collection time.
`limit`	No	Per artifact. Default 50.
`since`	No	ISO-8601 instant or window (7d, 24h). Or a version (v2) when addressing one artifact.
`until`	No
`cursor`	No	The previous cursor.next.
`fields`	No
`filter`	No	ANDed 'field op value' clauses: 'reps >= 5', 'day in mon,tue', 'note is set'. Ops: = != > >= < <= contains in, is set, is unset. System: _version _at _status _visitor.
`dataset`	No
`artifact`	No	Artifact id or slug.
`collection`	No	The gallery grouping label set at publish, case-sensitive. Not a content collection.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / collection / description

Previous value: -"Case-sensitive publish label."New value: +"The gallery grouping label set at publish, case-sensitive. Not a content collection."

First observedOct 27, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish read-only, non-destructive, closed-world behavior, but the description adds meaningful traits: newest-first ordering, cursor pagination, collection limits over one window, and that collection addressing does not accept a filter. The only gap is that some constraints are densely packed and the return shape is only partially described.

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 compact and front-loads the resource and key distinctions, with no filler. However, the sentence structure is very dense and parenthetical, which makes some constraints harder to parse than necessary.

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?

For a 10-parameter read tool with no output schema, the description covers the essential addressing model, ordering, pagination, and key sibling distinctions. It is still slightly incomplete about the precise returned structure and some parameter edge cases, but it gives an agent enough to call the tool correctly in most cases.

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%, so the schema carries much of the parameter documentation, but the description adds important semantics beyond it: artifact/dataset/collection are mutually exclusive addressing modes, dataset may be ambiguous, collection is a publish-time gallery label, and filter is not allowed for collection addressing. It still leaves some lower-level parameters such as until and fields largely 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 clearly identifies the resource: visitor-submitted rows for artifacts, returned newest-first with each version's field schema and cursor pagination. It also explicitly separates this from content-collection entries (super_entries) and aggregate queries (super_data_query), so an agent can distinguish it from siblings without inspecting other 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 gives explicit addressing rules: address exactly one of artifact, dataset, or collection, and it calls out the ambiguous_dataset case when a dataset is shared. It also names alternatives directly: content-collection entries are super_entries, and totals/averages are a query rather than this read.

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?