How agents find deed.page — llms.txt, skill.md, and the well-known files: deed.page

deed.page has no signup form. An agent finds it through a set of small, plain files at fixed URLs, learns the API from those, and publishes without asking anyone. This post walks through each file and shows how to check it yourself.

Every command below was run against production on October 8, 2026. The one test site used X-Ttl: 900 and was deleted afterwards.

Start at llms.txt

/llms.txt is a short plain-text summary for language models: what deed.page is, the one request that publishes a site, the response shape, the slug rules, the limits, and links to everything else:

curl -sS https://deed.page/llms.txt

It's short so it fits next to the user's task. An agent that wants everything in one fetch can read /llms-full.txt instead, which appends the full docs, the auth notes, a dated comparison table, and the FAQ:

curl -sS https://deed.page/llms-full.txt

The /blog index, these posts included, is linked from llms.txt too.

skill.md: a drop-in SKILL.md

/skill.md is a ready-made skill file: YAML frontmatter (name, description, version) and then instructions. The description lists the trigger phrases ("publish this", "host this", "put this online"). The body covers the publish commands, how to keep the token, the slug rules, and when to add X-Ttl or X-Spa.

Installing it for an agent that loads skills from ~/.claude/skills takes one line, which is also published in llms.txt:

mkdir -p ~/.claude/skills/deed-page && \
  curl -fsSL https://deed.page/skill.md -o ~/.claude/skills/deed-page/SKILL.md

To check whether a cached copy is out of date without downloading the whole file, ask the version endpoint:

curl -sS https://deed.page/api/skill/version

{"name":"deed-page","version":"1.1.0","url":"https://deed.page/skill.md"}

If the version doesn't match the frontmatter in your local SKILL.md, fetch it again.

The same skill is listed in /.well-known/skills/index.json, along with its homepage, its URL, and the install command, for tools that look for skills under .well-known.

Markdown for agents, HTML for browsers

/docs, /skill.md, /auth.md, and /pricing.md all check the Accept header. A plain curl gets text/markdown. A browser that asks for text/html gets the same content rendered as a page. So an agent never has to strip HTML to read the docs:

curl -sS -o /dev/null -w '%{content_type}\n' https://deed.page/docs
text/markdown; charset=utf-8

curl -sS -o /dev/null -w '%{content_type}\n' -H 'Accept: text/html' https://deed.page/docs
text/html; charset=utf-8

/index.md is a markdown version of the home page, and /openapi.json is an OpenAPI 3.1 description of the REST API for clients that generate tools from a spec.

The Link header

An agent that only knows the domain can find all of this from one HEAD request. Pages on deed.page itself return a Link header that points to the discovery files:

curl -sSI https://deed.page/ | grep -i '^link'

link: </llms.txt>; rel="alternate"; type="text/plain"; title="llms.txt", </openapi.json>; rel="service-desc"; type="application/openapi+json"; title="openapi", </skill.md>; rel="alternate"; type="text/markdown"; title="skill", </mcp>; rel="mcp"; title="MCP server"

Published sites at {slug}.deed.page do not get this header. Those pages belong to whoever published them.

The .well-known files

/.well-known/mcp/server-card.json names the MCP server (page.deed/deed-page) and its one remote, a Streamable HTTP endpoint at https://deed.page/mcp.
/.well-known/agent.json (also served as agent-card.json) is an A2A-style card. It lists the operator (Avatar 8 LLC), the docs, and the skills, and links to MCP, OpenAPI, llms.txt, and skill.md. deed.page speaks REST and MCP. It does not have an A2A JSON-RPC endpoint, so the card points to those two interfaces.
/.well-known/ai-plugin.json is a plugin manifest with auth: none that points to the OpenAPI spec.

/robots.txt allows every crawler, AI crawlers included, and lists the sitemap and the discovery URLs.

From discovery to a live URL over MCP

When the client supports MCP, initialize returns instructions with the same rules as skill.md, and tools/list returns the tools:

curl -sS https://deed.page/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

There are seven: publish_site, update_site, get_site, list_sites, delete_site, whoami, and get_upgrade_link. To add the server to Claude Code:

claude mcp add --transport http deed-page https://deed.page/mcp

Or over plain HTTP

An agent that has only read skill.md can publish with the inline JSON form it describes. This is the request we ran today, with a short TTL because it was a test:

curl -sS -X POST "https://deed.page/v1/sites" \
  -H 'content-type: application/json' -H 'X-Ttl: 900' \
  -d '{"slug":"discovery-check-<random>","files":{"index.html":"<!doctype html><h1>Hello</h1>"}}'

The response included url, path_url, version: "v1", expires_at, and a token that is shown only once. Both URLs returned 200. Then we deleted the site with that token:

curl -sS -X DELETE "https://deed.page/v1/sites/discovery-check-<random>" \
  -H "Authorization: Bearer $DEEDPAGE_TOKEN"

{"ok":true,"deleted":"discovery-check-<random>"}

Leave out X-Ttl and the site is permanent.

What the files ask of agents

The discovery files also carry the rules. Keep the token in an environment variable and never paste it into a page. Treat every site as public. Don't reuse the example slugs, which are reserved. If you only read one file, read /llms.txt. It links to the rest.