Most Model Context Protocol connectors let an agent read data. thethings.ai flips that direction — it gives an agent a place to write, turning generated HTML into a live public URL without a deploy step.
What thethings.ai delivers to AI immediately
thethings.ai is a hosted publishing surface built for AI agents: an agent writes an HTML page, report, dashboard, or app, makes one call, and gets back a shareable public URL with no build step and no separate hosting account . The homepage describes itself as "the web home for AI agents" and connects over MCP "in under a minute" . The result a session would normally hand back as a file, screenshot, or local preview becomes a clean URL on the open web instead.
It exposes three interface modes around one set of operations:
- MCP server at
thethings.ai/mcp, addable to MCP-capable clients . - CLI (
things publish) — though whether it is publicly packaged is not documented . - REST endpoint for direct HTTP workflows .
All three expose the same five core operations: write, read, list, str_replace, and delete . The named client-setup targets on the site are Claude.ai, ChatGPT, Cursor, VS Code, and Claude Desktop, with documented setup time under a minute .
One distinction matters up front: thethings.ai is not a generator. It supplies the hosting and URL leg only — the calling agent (Claude, a GPT model, Codex, or any HTTP-capable workflow) writes all the content . That is a deliberate inversion of how MCP is usually wired. Anthropic introduced MCP as an open standard for connecting agents to external systems, and most early connectors are read-oriented . thethings.ai uses the same protocol to write and update web-published artifacts instead — and carries a © 2026 copyright, marking it as a current, newly live surface .
Anonymous scratch vs. claimed namespace: the difference
thethings.ai ships two publishing tiers, and the split is the first thing to understand before wiring it in. The anonymous tier is credential-free and append-only; the claimed tier is token-scoped and editable. Choosing between them is a choice about whether a write is permanent and public, or owned and revisable .
For the anonymous path, you POST to https://thethings.ai/api/scratch/publish with a JSON body. Only content is required; content_type, title, and summary are optional. The response includes a url field pointing at the live page .
POST https://thethings.ai/api/scratch/publish
{ "content": "<h1>Status</h1>", "content_type": "text/html" }
Scratch pages land in a shared public space, receive a unique slug, and cannot be edited or deleted afterward. Treat every anonymous write as permanent — there is no undo, no patch, no takedown call documented . The MCP equivalent is the same idea over the protocol: connect to https://thethings.ai/mcp-public and call the publish_anonymous tool, with no credentials at all .
The claimed tier trades that openness for control. You authenticate with a per-site token prefixed ttp_, or via OAuth on clients that support it. Pages become editable, and you get multi-site namespaces, scoped-token isolation, and edge-cached delivery using Cache-Control, ETag/304, and stale-while-revalidate . Edits use atomic, server-side str_replace patching rather than full re-uploads .
| Property | Anonymous scratch | Claimed namespace |
|---|---|---|
| Credentials | None | ttp_ token or OAuth |
| REST endpoint | /api/scratch/publish | Authenticated /mcp |
| MCP endpoint / tool | /mcp-public, publish_anonymous | /mcp, pages_write et al. |
| Editable after write | No — append-only | Yes — atomic str_replace |
| Namespaces | Shared public space | Multi-site, scoped-token isolation |
| Delivery | Public slug URL | Edge-cached (Cache-Control, ETag) |
The practical rule: use anonymous scratch for throwaway, one-shot artifacts an agent can fire without onboarding, and accept that those URLs are permanent. Use a claimed site for anything you expect to update — dashboards, status pages, proposals — where editability, isolation, and cache control actually matter .
A direct write route to the internet for AI
thethings.ai inverts the most common MCP pattern: instead of reading data into an agent, it lets the agent write a new artifact and persist it to a live URL. The Model Context Protocol was announced by Anthropic on November 25, 2024 as an open standard for connecting AI applications to external systems . The large majority of connectors built since are read-oriented — query a database, return structured data. thethings.ai uses the same protocol in the opposite direction.
That distinction matters because the other agent-publishing tools shipping in 2026 each keep a leg that thethings.ai removes:
- WordPress.com announced MCP access on March 20, 2026, letting AI draft, edit, and publish posts . But autonomous writes are gated: AI-written posts are saved as drafts by default and changes require user sign-off.
- HTML Anything (covered May 23, 2026) is local-first — it generates a single-file HTML export using whichever agent is already logged in locally . There is no remote hosting leg; the output lives on disk or in a paste.
- thethings.ai occupies the hosting-endpoint slot with an explicitly anonymous, ungated write path — no human-in-the-loop by design .
| Platform | Write path | Human approval | Hosting |
|---|---|---|---|
| thethings.ai | MCP / REST / CLI | None by default | Public slug URL |
| WordPress.com | MCP | Required (drafts) | Your WP site |
| HTML Anything | Local agent | Local edit loop | Disk / paste |
The trade-off is direct: removing the approval step also removes the governance layer. An anonymous publish lands on the open web with no review, no editing, and a permanent slug. OpenAI's own MCP guidance frames the risk class:
"Custom MCP servers are third-party services; write actions carry more risk than read-only tools, and prompt-injection or excessive-parameter risks should be weighed before connecting a server." — OpenAI MCP documentation (source: thethings.ai)
For developers, that is the design choice to weigh. WordPress.com trades autonomy for a safety net; HTML Anything trades reach for local control. thethings.ai maximizes autonomy and reach at once — which is exactly why the missing controls, covered next, are the part to read closely.
Currently unconfirmed: SLA, moderation, and retention
thethings.ai ships an open write surface with almost no published operational contract. As of June 2026, no indexed public document specifies an SLA, an uptime page, or rate limits . That means behavior at volume — or during an outage — is undefined. For a service whose whole pitch is "publish in one call," the absence of throttling and availability documentation is the first thing to flag before you route production writes through it.
The governance gap is wider on the anonymous path. There is no moderation policy, no abuse-reporting route, and no statement on whether anonymous JavaScript is sandboxed or restricted . Combined with an unauthenticated publish_anonymous endpoint, that leaves an open write surface with no visible governance layer — a standing spam and SEO-abuse question.
Retention is equally unspecified. No pricing page, terms of service, or changelog is published, and scratch pages carry no documented TTL or deletion mechanism . Anonymous pages already cannot be edited after creation; whether they ever expire is unknown.
The product surface around it is thin too:
- No custom-domain support or enterprise controls are documented .
- The CLI is referenced but unpackaged —
things publishappears in the docs, yet no installable package is linked . - No public provenance — no press release, funding announcement, GitHub repository, or third-party adoption coverage exists in indexed sources .
Even the launch date is inferred, bounded only by the visible 2026 site copyright rather than any announcement timestamp . None of this makes the technical pitch wrong — the primary-source mechanics hold up. It does mean the trust signals you would normally check before granting an agent write access to the open web are not yet there to check.
What to clarify before you wire thethings.ai in
So the first work is policy, not code. Decide which agent sessions hold write access and which data class is allowed to become externally visible. This matters most on the anonymous tier: pages published through publish_anonymous or POST /api/scratch/publish land in a shared scratch space with a unique slug and cannot be edited later . With no documented deletion path for scratch pages, every anonymous write is effectively permanent and public.
Treat the write path as a higher-risk surface than a read connector. OpenAI's MCP documentation makes the distinction explicit:
"Write actions carry more risk than read-only tools, and prompt-injection or excessive-parameter risks should be weighed before connecting a server," — OpenAI MCP documentation (source: platform.openai.com/docs/mcp).
Walk a prompt-injection scenario before any unsupervised use: if a session can be steered to publish, the blast radius is a live URL on the open web, not a discarded draft. Practical guardrails to settle first:
- Token handling: store the per-site
ttp_token in secrets management, never in prompt context or conversation history — a leaked token allows arbitrary writes to a claimed namespace . - Content class: confirm generated pages cannot carry PII, competitive data, or unfiltered user-supplied input before enabling any autonomous write cadence — no sandbox or CSP policy is documented for the anonymous tier .
- Approval gate: decide whether writes require user confirmation, especially while the platform exposes write,
str_replace, and delete operations through MCP, REST, and CLI .
The takeaway: thethings.ai is a clean, primary-sourced write surface, but the controls are yours to impose, not the platform's to enforce. Scope the tokens, gate the writes, and start on a claimed namespace you can edit — keep the anonymous, undeletable path out of any automated loop until governance details are published.
Frequently asked questions
What is thethings.ai and how does it differ from a static site host?
thethings.ai is a write endpoint for AI-generated artifacts, not a human CMS or static site builder. An agent calls it once to turn generated HTML, a report, a dashboard, or a mini-app into a public URL with no build or deploy step . The distinction is authorship and workflow: a static host expects a human to commit files and trigger a pipeline, while here the agent is the author and the publish happens inline during a session in Claude, ChatGPT, Cursor, or Codex .
Can I publish to thethings.ai without creating an account?
Yes. Send a POST to https://thethings.ai/api/scratch/publish with a JSON body containing at minimum the content field; the response returns a url . Anonymous pages land in a shared public scratch space, receive a unique slug, and cannot be edited or — based on documented behavior — reliably deleted later . No credentials are required, which is convenient for one-off output but unsuitable for anything you may need to revise or remove.
How do I connect thethings.ai to Claude or ChatGPT via MCP?
Add an MCP endpoint to your client config: https://thethings.ai/mcp for authenticated use or https://thethings.ai/mcp-public for anonymous publishing via the publish_anonymous tool . The site lists Claude.ai, ChatGPT, Cursor, VS Code, and Claude Desktop as supported clients and documents setup over MCP in under one minute . Authenticated clients can use OAuth, with bearer-token headers or a key query parameter as fallbacks.
What file types can be sent to thethings.ai?
Text formats: HTML, CSS, JavaScript, Markdown, JSON, and similar . Pass content_type in the POST body to control how the browser serves the page, since the platform writes content to a slug and returns it with an appropriate content type . Binary formats are not part of the documented surface — treat it as a text-artifact target, not a general file host.
Is thethings.ai ready for production use in an autonomous agent?
Not yet, on public evidence. As of June 2026 the maturity signals are thin: no published SLA, rate-limit documentation, moderation policy, retention rules, or pricing page were found beyond the live site . It is well suited to experimentation and internal tooling. For production or customer-facing use, define token storage, the acceptable data classes an agent may publish, and a deletion or expiry strategy first — and keep the anonymous, immutable scratch path out of automated loops until governance details are published.
