MCP

An endpoint for agents that cannot make an arbitrary HTTP request.

Every other path into the serving plane assumes the agent can issue an arbitrary HTTP request. A command-line agent can; a hosted chat assistant cannot — it reaches external tools through a connector, where the vendor's own cloud speaks MCP to a public endpoint on the user's behalf.

Without one of those, "works with a hosted assistant" would mean "can be told about Super Artifacts and then do nothing".

The endpoint

https://api.superart.page/mcp

The credential is a creator key, sent either as Authorization: Bearer or as a path segment (/mcp/sa_live_…). The path form exists because the connector interfaces accept a URL and, without OAuth, offer no way to attach a header.

A key in a URL is a real trade — it lands in the client's stored configuration — so it is a deploy credential scoped to one account's own artifacts, revocable from the dashboard, and never an admin secret. That is the same trade the deploy endpoint already makes, made visible.

Both protocol revisions

Revision 2026-07-28 removed the initialize handshake, protocol-level sessions and the GET stream. The shipping clients still open with initialize and a session header. A server that implements only one era fails against half the clients it was written for, so this one answers initialize when it arrives and does not require it, accepts a request with or without a protocol version header, and echoes back a version it recognises.

Every answer is one envelope

Every tool answers { "ok": true, ... }, or { "ok": false, "code", "message" } flagged as an error, both as JSON text and as structured content. A failure is a result rather than a protocol fault: the caller is a model, and a result it can read and act on is worth more than an error frame its runtime swallows. The code is stable; when the next call is likely, next names it; when a tool was addressed wrongly, accepts lists the forms it takes.

Sixteen tools

One noun each — super_publish, super_artifacts, super_artifact_set, super_data, super_data_query, super_data_schema, super_entries, super_templates, super_template_save, super_template_action, super_release_template, super_playlist, super_share, super_comments, super_whoami — plus super_help, which returns short usage notes on demand instead of the server paying for them in every session. Names from before 29 September 2026 still answer for one release cycle.

Reading collected data back

This is built. An artifact that shipped with a data policy hands its rows back to the agent that published it, over this same endpoint and with the same key:

  • super_data with artifact — one artifact's rows, with the declared schema of every version alongside them, so a field added in v3 is legible next to a row written under v1.
  • super_data with collection — every artifact sharing a collection label, read over one window. Use this rather than reading artifacts one by one in a loop: no member is missed because a slug was forgotten, and no two are compared over different spans.
  • super_data_query with distributions — totals and distributions rather than rows, for when the question is "how many" and not "which".

Filters are the same everywhere: ANDed 'field op value' strings such as 'reps >= 5'.

super_publish takes the policy that switches all of this on. An artifact deployed without one collects nothing, so the tool says what the artifact collects in its own reply — that response is the only place it is ever stated. See Collecting data.