MCP

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.

Failures come back as results

A tool that fails returns a result describing the failure rather than a protocol fault. The caller is a model: a result it can read and act on is worth more than an error frame its runtime swallows.

What is not there yet

Reading collected data over MCP is not built. The product's shape is that data an artifact collects flows back to the agent, and the mechanism for that — visitor tokens, data policies, the client SDK — has not shipped. What the endpoint does today is deploy. Anything you read describing an agent querying its artifacts' responses is describing the intent.