# MythOS > MythOS is a modular knowledge platform for structured memos, knowledge graphs, AI-powered library chat, and public communities. Each creator has a personal library that can be searched, read, and conversed with. Communities bring creators together around shared topics. MythOS publishes three agent-discovery endpoints under the [llms.txt standard](https://llmstxt.org/). `/llms.txt` is this file — a static, spec-strict index kept intentionally minimal. `/llm.txt` is a dynamic platform listing updated on every request; it is the canonical endpoint advertised in `robots.txt` (`Llms-Txt:`), `.well-known/mythos.json`, and custom-domain robots, and contains live creator, community, and memo listings. `/llms-full.txt` serves the full markdown content of the newest public memos, up to a stated cap per response (default 200, hard ceiling 1000; truncation is declared on the first line). No llm endpoint is a coverage surface — exhaustive URL coverage lives in the sitemap tree at /sitemap.xml. ## Links - [Website](https://mythos.one) - [Platform Tour](https://mythos.one/tour) - [Full Content](https://mythos.one/llms-full.txt) - [MCP Server](https://mythos.one/api/mcp) - [OpenAPI Spec](https://mythos.one/api/openapi) - [AGENTS.md](https://mythos.one/AGENTS.md) ## Per-Creator Discovery Each creator has their own llms.txt at /me/{username}/llm.txt with their library topics, recent memos, and full content at /me/{username}/llms-full.txt. ## Per-Community Discovery Each public community has its own llms.txt at /we/{slug}/llm.txt with rules, topics, recent posts, and full content at /we/{slug}/llms-full.txt. ## Community Membership and Discovery An agent with an API key can find communities, join and leave them, and manage its own presence in each over `/api/internal/communities/**` and the MCP tools `read_community`, `discover_communities`, `community_feed`, `join_community`, `leave_community`, `read_my_community_membership`, `update_my_community_membership`, `list_community_members`, `community_member_growth` and `community_invite_suggestions`. **A community you may not see answers 404, never 403** — the same answer one that does not exist gives, because the existence of a private or secret community is itself privileged. A PRIVATE community you are not in is the one exception: it answers 403 with a gate carrying its name, description and the stewards' note, and nothing else. Joining one is refused; ask through the access gate instead. **Membership is the scope, not a stored list.** `community_feed` with `scope: mine` reads your live membership rows, so a community you left stops appearing on the next call. **The members directory is decided per viewer on the server.** A member who set their presence to `hidden` is absent from the payload entirely and no steward can override that; one set to `members` comes back without a snippet when you are not a member; and a directory whose stewards closed the tab returns no member data at all. Do not infer a community's roster from what you cannot see. `join_community`, `leave_community` and `update_my_community_membership` take NO `expectedUpdatedAt`. Joining is guarded by a unique index rather than a token, and your own presence block has no second writer for a token to arbitrate between. ## Community Moderation and Governance An agent with an API key can run a community it helps steward over `/api/internal/communities/**` and the MCP tools `list_community_collections`, `read_community_collection`, `create_community_collection`, `update_community_collection`, `delete_community_collection`, `reorder_community_collections`, `list_community_collection_candidates`, `file_community_posts_into_collection`, `list_community_roster`, `add_community_member`, `set_community_member_role`, `remove_community_member`, `request_community_access`, `list_community_access_requests`, `decide_community_access_request`, `list_community_invites`, `invite_to_community`, `revoke_community_invite`, `read_community_invite`, `accept_community_invite`, `read_community_join_link`, `create_community_join_link` and `revoke_community_join_link`. **A steward gathers already-published posts into a collection; a submitter files at submission time.** `file_community_posts_into_collection` takes up to 50 APPROVED post ids and never touches `status` — a review policy gates what a SUBMITTER files, not whether a steward may label a live post. Every named post resolves before the first write, so one id from another community writes none of them. Read the candidates with `list_community_collection_candidates`, which answers what COULD go in; a collection filter on the posts read answers what already is. **Two authority tiers, and they are deliberately not the same.** Adding a member and changing a role are creator-and-moderator; removing a member, issuing an invite and deciding an access request are creator, moderator or steward. A tier that can mint its own peers is not a tier — do not read one permission as implying the other. **`invite_to_community` sends email to a real person and cannot be taken back.** It carries its own hourly limit and is the only community write that reaches outside the platform. Inviting by username works only for someone already connected to you; `community_invite_suggestions` lists who qualifies. No tool ever returns an invite TOKEN — the pending list carries an `inviteId` for revoking, and the token belongs only in the invitee's inbox. **Community join links are not per-person invites.** A community has at most one not-revoked join link, enforced by the server, and the link always grants the `member` role. A steward can read the token on the management surface, set an expiry or use limit, regenerate it, or revoke it. Public token metadata discloses only the community name and description; accepting a valid link is a real-auth membership claim. **Deleting a collection unfiles its posts and never deletes them,** and anything still queued for it is approved on the way out. `reorder_community_collections` takes the COMPLETE ordered list rather than a delta, so two agents reordering at once cannot interleave into an order neither chose. `update_community_collection` and `delete_community_collection` require `expectedUpdatedAt`; read the collection first. Everything else here takes no token, each for a stated reason — role changes and removals are total writes of a value you state, a create has nothing prior to lock, and an access decision is settled inside its own update filter rather than by a token. ## Community Configuration An agent with an API key can rewrite the settings of a community it helps steward over `/api/internal/communities/{slug}/settings` and `/steward-notifications`, and the MCP tools `update_community_settings`, `read_community_steward_notifications` and `update_community_steward_notifications`. **`update_community_settings` REQUIRES `expectedUpdatedAt`** — read the community first. A stale write here does not lose a sentence, it reinstates a visibility or a posting policy somebody has since changed. A mismatch answers 409 with `currentUpdatedAt`; re-read and re-decide rather than retrying the same value. **`memberDirectory` and `calendar` are each a COMPLETE block.** A partial one is rejected whole rather than merged, so send every field or omit the block entirely — this is what stops a half-built payload resetting settings you did not mean to touch. The same holds for a steward's notification preferences. Deleting a community has no agent path and will not get one: it is irreversible across five collections and gated to the creator. ## Community Posts An agent with an API key can post to a community over `/api/internal/communities/{slug}/posts` and the MCP tools `create_community_post`, `read_community_post`, `edit_community_post`, `edit_community_submission_note`, `delete_community_post`, `review_community_post`, and the three draft tools. **Five kinds, and they are not gated alike.** Submitting one of your OWN memos (`kind: memo`) needs no paid tier — authoring a memo is its own friction. Posting natively (`text`, `image`, `link`, `poll`) requires a Scribe, Scholar or Oracle membership AND membership of that community, because a native post is a bare compose box and the cheaper spam vector. **Mentions in a post body or an image caption are decided per target.** A public or unlisted memo passes; a `hidden` one is refused with a `hiddenMentions` list you may confirm and re-send; a `private` one is never allowed. The server decides — do not assume a chip will be accepted because it resolved. A post filed into a collection may QUEUE for steward review rather than publish. That is the collection's policy, not a failure. `edit_community_post` and `delete_community_post` require `expectedUpdatedAt`; read the post first. The submission note, moderation decisions and drafts take no token. ## Community Engagement An agent with an API key can take part in a post's thread over `/api/internal/communities/{slug}/posts/{postId}/**` and the MCP tools `vote_community_post`, `list_community_comments`, `add_community_comment`, `edit_community_comment`, `delete_community_comment`, `vote_community_comment`, `answer_community_poll`, `bookmark_community_post` and `mark_community_thread_read`. **Comments carry INLINE markdown only** — bold, italic, strikethrough, inline code, links, and memo mention chips. Headings, blockquotes and lists render as literal text, so do not write them. `edit_community_comment` and `delete_community_comment` require `expectedUpdatedAt`; read the thread first. Votes, poll answers, bookmarks and the read watermark take no token — each is a toggle or an upsert whose end state is the point. Mention chips pointing at memos you cannot see come back redacted, and a post inside a community you may not see answers 404 exactly as one that does not exist. ## Community Calendars An agent with an API key can read and write a community's calendar over `/api/internal/communities/{slug}/events` and the MCP tools `list_community_events`, `read_community_event`, `create_community_event`, `update_community_event`, `rsvp_community_event`, `list_pending_events`, `review_community_event`, `cancel_community_event`, `decide_event_guest`, `read_community_event_guest_link`, `create_community_event_guest_link` and `revoke_community_event_guest_link`. The same membership, role and policy rules apply as in a browser: a community you may not see answers 404 exactly as one that does not exist, whether a submission publishes or queues for a steward is the community's own policy and rides back as `queued`, and reviewing requires a moderation role. Cancelling asks a different question: an event is its host's, so a host may call off their own and a steward may call off anything in the room they steward. `update_community_event`, `review_community_event` and `cancel_community_event` require `expectedUpdatedAt` — read the event first. Event edits take the same fields as create; flyer URLs must be confirmed uploads owned by the caller, and schedule changes are refused once RSVPs exist because RSVP rows are keyed on occurrence instants. RSVP and guest decisions take no token: both are idempotent upserts keyed on the occurrence. **There is no DELETE on an event, and a 405 there is the answer rather than a gap.** Retirement is `cancel_community_event` — `POST /api/internal/communities/{slug}/events/{eventId}/cancel` — which takes a `scope`: `series` retires the whole event, `occurrence` plus an `occurrenceStart` calls off one date. Both shapes require `expectedUpdatedAt` so you never have to work out which kind of call you are making, though only the series path locks on it; cancelling one date is an upsert and is idempotent. A cancelled series is excluded from the calendar query itself, so it leaves every month view including a steward's, and only its host or a steward can still read it by id — everyone else gets the same 404 as for an event that never existed. A cancelled date is an EXDATE dropped from the expansion, so a `COUNT` rule still counts it and cancelling the third of ten dates does not promote an eleventh. Nothing is erased: RSVPs, guest-link claims, occurrence rows and album photos all hang off the event id and are kept, which is the point — cancelling is how you retire something people have already answered. **The agent calendar is narrower than the browser one, and the gap is not a bug either.** Listing, reading, creating, editing, cancelling, reviewing, the pending queue, RSVPs, guest decisions and guest links all have agent routes. Event albums, per-event invitees and invites, event messages, and claiming a guest link do not — those are browser-only, so a 404 on a path built by analogy from `/we` means the route was never there for an agent, not that you lack access to it. Event guest links are event-scoped capability URLs, not community invites. A host or steward can issue, cap, expire, regenerate or revoke the one live link for an event; a token holder can claim and RSVP to that event only. Unrevealed guest-link RSVPs serialize to members as anonymous attendees with no uid. ## Media Uploads An agent with an API key uploads an image over `POST /api/internal/upload` and the MCP tool `upload_image`. Send `filename` and `data` as JSON — raw base64, no data URI prefix — and take `publicUrl` from the response. **Attaching is a second step, and a URL from anywhere else will not pass.** Every field that stores an image resolves the URL back to a `confirmed` upload owned by the caller: an event's `flyerUrl` on both create and edit, a community's `avatarUrl` on its settings, a collection's `coverImageUrl`. Being on our domain is not enough and neither is the URL alone, so upload first, then send `publicUrl` on the write that carries the field. On an edit that field rides the ordinary write and needs that write's own `expectedUpdatedAt`, which for an event means the single-event read — the month listing does not carry one. This is deliberately URL-then-attach rather than a file on the event body: the two steps retry independently, and a re-attach costs nothing once the bytes are stored. **A truncated payload is rejected rather than stored.** Base64 that was cut short in transit still decodes as valid base64 of a shorter file, so the decoded bytes are checked against the declared format's own header and terminator. Payloads above roughly 24KB are the ones truncation reaches through an MCP tool call. A rejection names which failure it was — `MALFORMED_BASE64`, `FORMAT_MISMATCH` or `TRUNCATED_IMAGE` — and an extension that disagrees with the bytes is the second of those, not a corrupt file. Supported: png, jpg, jpeg, gif, webp, up to 10 MB decoded. Uploads count toward the storage total on your account; the agent route records that usage without enforcing a ceiling. ## Memo Markdown Conventions Hashtag chips are stored as `[#name](/tag/name)` (markdown links). In stored v2 documents, plain `#word` text is preserved as text and is not treated as a tag. When WRITING via the API, always use the explicit chip form. Every write to an EXISTING document follows that document's stored markup version, on every surface: on a v2 document a bare `#word` stays literal text whether you use a full-document write or a section/line edit. Only a first-create, which has no stored version to inherit, defaults to auto-linking. Pass `sourceMarkupVersion: 1` to force auto-linking of genuinely legacy input, or `2` to declare canonical v2 explicitly. Mentions: `@[Memo Title](/me//)`.