Using June.dev from an agent

June.dev serves the same canonical docs in several machine-friendly forms. Prefer MCP when the client supports it; otherwise give the agent llms.txt or a page's Markdown URL. They're alternate interfaces to the same content, not separate documentation.

What to give your agent

Your client supports MCP? Connect the MCP server at https://june.dev/mcp. The agent searches and reads the docs as tools while it works.
No MCP, but the agent can fetch URLs? Give it https://june.dev/llms.txt, the index of every page, and let it fetch the pages it needs.
Need one exact page? Give it that page's URL ending in .md, or have it request the page with Accept: text/markdown.

To tell an agent in one line:

Use June's docs at https://june.dev/mcp (or https://june.dev/llms.txt); verify API details there before coding.

Every interface

To get	Use
search and retrieval as tools	the MCP server at https://june.dev/mcp
an index of every page	https://june.dev/llms.txt
one page as Markdown	the page's URL with `Accept: text/markdown`, or the same URL ending in `.md`
the docs' structure	https://june.dev/docs/sitemap.md
every page in one file	https://june.dev/llms-full.txt

Given only https://june.dev, an agent can find the rest: the homepage's Markdown lists every interface above.

In this section

MCP server: connecting a client, the search_docs and get_doc tools, and june:// resources.
Markdown and discovery: content negotiation, .md URLs, llms.txt, llms-full.txt and the docs sitemap.
Skills: there's no official June skill yet, and what one would add.

What the interfaces cover

Every agent interface carries the same pages as this sidebar: June's docs and its example guides. They don't include the design system's docs, June's source code, or anything private.

Consistency. All of them are generated from the docs' own sources and nav, so a page added to the docs shows up in each of them, and none can say something the HTML page doesn't.