Klasyczna dokumentacja powstaje z myślą o człowieku: wyrenderowany HTML, podświetlanie składni, pasek boczny, wyszukiwarka. Coraz częściej jednak po docs porusza się nie człowiek, lecz agent (Claude, Cursor, ChatGPT), któremu cały ten rendering tylko przeszkadza. Potrzebuje czystego tekstu i kontraktu do odczytu maszynowego.
Przygotowaliśmy dokumentację tak, żeby nadawała się dla obu. Oto co jest pod maską.
Wersja .md każdej strony
Dział zatytułowany „Wersja .md każdej strony”Każda strona dokumentacji ma surową wersję w Markdownie pod tą samą ścieżką z sufiksem .md. Otwierasz /agent-setup, a obok jest /agent-setup.md: ten sam tekst bez otoczki HTML, z wyciętymi importami MDX, serwowany jako text/markdown.
Z tego korzystają dwie akcje w menu strony: Copy as Markdown (kopiuje czysty tekst do schowka, żeby wkleić go do czatu z modelem) i View as Markdown (otwiera bezpośrednio wersję .md). Agent nie musi parsować DOM, tylko pobiera gotowy tekst.
Menu akcji u góry strony
Dział zatytułowany „Menu akcji u góry strony”W prawym górnym rogu każdej strony jest menu akcji, zaprojektowane właśnie pod pracę z agentami:
- Copy as Markdown - czysty tekst strony do schowka
- View as Markdown - otwarcie wersji
.md - Open in ChatGPT - przekazanie strony do ChatGPT jednym kliknięciem
- Open in Claude - to samo dla Claude
- Connect MCP - przejście do konfiguracji serwera MCP
Zamiast “skopiuj URL, otwórz czat, poproś o wejście na stronę” wystarczy jedna akcja.
llms.txt i llms-full.txt
Dział zatytułowany „llms.txt i llms-full.txt”Zgodnie ze standardem llmstxt.org udostępniamy dwa pliki:
/llms.txt- indeks wszystkich stron dokumentacji, pogrupowany w sekcje (API Reference, Use Cases, Examples, Products). Mapa, która mówi agentowi, od czego zacząć./llms-full.txt- cała dokumentacja w jednym pliku tekstowym. Do indeksowania offline w bazie wektorowej albo do jednorazowego wklejenia w kontekst modelu.
Jeśli budujesz RAG na bazie naszego API, llms-full.txt to gotowy korpus, nie trzeba crawlować strony.
Specyfikacje do odczytu maszynowego
Dział zatytułowany „Specyfikacje do odczytu maszynowego”Kontrakt jest udostępniany w kilku formatach pod różne narzędzia:
/v1/openapi.json- kanoniczna specyfikacja OpenAPI 3.1 z przykładami i code samples. Do generowania klientów i dla dowolnych narzędzi OpenAPI.- Aliasy Swaggera -
/v1/swagger.json,/v1/v3/api-docsi inne przekierowują kodem 301 na kanoniczny plik, żeby narzędzia szukające typowych ścieżek się nie potykały. - Kolekcja Postmana -
/postman/astroway-api.jsondo importu w Postmanie jednym kliknięciem.
/agent-setup pod konkretnych klientów
Dział zatytułowany „/agent-setup pod konkretnych klientów”Strona /agent-setup/ to nie jeden ogólny poradnik, lecz osobne instrukcje dla siedmiu klientów: Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Cline, Codex. Każda podaje dokładną konfigurację i przykład curl dla tools/list, żeby sprawdzić połączenie, zanim zaczniesz pisać kod.
Wbudowane try-it
Dział zatytułowany „Wbudowane try-it”Na stronach dokumentacji API każda operacja ma wbudowany widżet try-it: wklejasz klucz sandbox, edytujesz treść żądania, klikasz “Send” i widzisz prawdziwą odpowiedź bez wychodzenia z docs. Metoda, ścieżka i przykładowa treść są pobierane z już wygenerowanego snippetu curl, więc widżet nie wysyła dodatkowych żądań po openapi.json.
Po co to wszystko
Dział zatytułowany „Po co to wszystko”Prosta teza: jeśli twoim produktem jest API, dokumentacja musi nadawać się nie tylko do czytania, ale i do przetwarzania przez agenta. Połowa integracji zaczyna się dziś od tego, że programista wrzuca link do docs do Claude albo Cursora i prosi “podłącz to”. Zadbaliśmy o to, żeby po drugiej stronie był czysty tekst i kontrakt maszynowy, a nie HTML, który trzeba parsować.
Sprawdź sam: otwórz dowolną stronę docs, kliknij menu akcji w prawym górnym rogu, a zobaczysz “Open in Claude”.
Ten sam Swiss Ephemeris, co w Solar Fire - w 4 liniach kodu.
Darmowy klucz bez karty. 5 000 wywołań miesięcznie do pierwszej płatności.