Reading and editing OneFront pages programmatically

1. Reading — no auth

The MCP server is public and stateless. Point any MCP client at it:

https://onefront.org/api/mcp

Or skip MCP entirely — every profile publishes a plain-text summary at /<username>/llms.txt and schema.org JSON-LD in the page itself.

• get_profile — identity: name, tagline, bio, entity type
• list_links — the page's links in display order
• list_latest_items — newest podcast episodes, videos, or posts, with dates and durations
• list_social_accounts — linked social identities (sameAs)
• get_verified_accounts — only accounts that passed rel=me verification
• search_profiles — find profiles by name, tagline, bio, or username
• record_link_click — follow a link on the user's behalf and return its destination
• check_username_availability — whether a username can be claimed

2. Getting a key

The page’s owner creates one under Dashboard → Agents. Keys start with of_live_, are shown once, act only on that one profile, and can be revoked instantly. A key can be read-only or read-and-edit.

A key cannot mint other keys, and it cannot change the username — renaming breaks every link anyone has already shared, so it stays a deliberate human action.

3. Editing over MCP

Send the key as a bearer token. The write tools appear in the tool list only when the key is valid, so an unauthenticated client never sees a tool it can’t call.

{
  "mcpServers": {
    "onefront": {
      "url": "https://onefront.org/api/mcp",
      "headers": { "Authorization": "Bearer of_live_YOUR_KEY" }
    }
  }
}

• whoami — which profile this key edits — call first to confirm
• update_profile — display name, tagline, bio, entity type, theme
• list_my_links — your links with ids and real destinations
• add_link / update_link / remove_link — manage links
• reorder_links — set display order (pass every id)
• add_social_account / remove_social_account — manage sameAs identities
• connect_feed — attach an RSS/Atom feed that auto-updates the page
• list_feeds / refresh_feed / disconnect_feed — manage feeds

4. Editing over HTTP

The same key authenticates the REST API. These are the endpoints the dashboard itself uses, so they can’t drift from what the product actually does.

curl -X PATCH https://onefront.org/api/profile \
  -H "Authorization: Bearer of_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tagline":"Now shipping weekly"}'

curl -X POST https://onefront.org/api/links \
  -H "Authorization: Bearer of_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"label":"New episode","url":"https://example.com/ep/42"}'

curl -X POST https://onefront.org/api/feeds \
  -H "Authorization: Bearer of_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://feeds.example.com/show.xml","kind":"podcast"}'

Errors come back as {"error": "…"} with a real status code: 401 unknown or revoked key, 402 account not on Pro, 403 read-only key attempting a write, 404 not yours, 400 validation.

5. Auto-updating feeds

Rather than pushing every new episode or post by hand, connect the source once and OneFront polls it. New entries appear on the page and in its structured data within about half an hour, typed as PodcastEpisode, VideoObject, or BlogPosting— with publish dates, durations, and episode numbers, so “what’s their latest episode?” has a real answer.

RSS 2.0, Atom, and podcast feeds all work. Use refresh_feed (or POST /api/feeds/:id) to publish something immediately instead of waiting for the next poll.