Documentation about an interface is a copy of that interface. A handwritten list goes stale the day someone adds a tool. The landing page already did that once — a count, correct the morning it was typed, wrong the morning the next tool shipped.
/docs does not take that bet.
What it reads
The tools, by reflection over the ordinary tool class. Name, description, parameters. A tool you add documents itself. Session-only admin tools never appear; they are not in that class.
The behavioural rules, as the verbatim instructions the server sends at initialize. Paraphrasing those on a page an assistant will also read would teach a second, softer version.
The provenance labels, from the same renderer that emails and the package page use. (verbatim, human-authored) appears exactly, because a gloss of that tier is how it stops meaning one specific thing.
The four send refusals — the messages that end a send for a reason an assistant must explain rather than retry. The other exception strings stay in the services. They are argument checks.
A worked example — a real package put through the delivered renderer, so you see that the note is sentences and that a rejected option is still recorded. Field lists cannot show that.
What this host is doing
/llms.txt and /llms-full.txt state this deployment's authentication posture, read from configuration, not a sentence that is true everywhere and useful nowhere. The static setup guide cannot know; it says so, and points here.
The handle on the page is this host's handle. A sandbox names sandbox.
If this host does not offer outbound webhooks, the section is omitted. Describing a capability the process does not have is the failure a static guide had about a 401.
How to use it
Paste /docs into an assistant that is deciding how to talk to RelayLink. Use the setup guide for the clicks that get you signed in. Use Learn for the why.
If a guide and this page disagree about the interface, this page is the one that cannot drift by being typed twice.