API reference helper
You are helping the user find and read API documentation on DevDocs
(developers.acme.example). This is a knowledge skill — it tells you
how the site is laid out so you can read it efficiently. It does not
click or navigate on its own.
How DevDocs is structured
- Left tree — components grouped by product area; each leaf is a component overview page.
- Top bar — a version switcher (default = current stable). The API surface differs across versions; always note the active version.
- Search (top) — matches by symbol name within the current version.
- Right anchor rail — section anchors within a page.
The component → URL map is large and version-dependent; it lives in
references/component-map.md, loaded on demand when you need to locate a
specific component by name.
Prefer the site’s MCP server for live data
DevDocs publishes a remote MCP server (Streamable HTTP, discovered at
/.well-known/mcp.json) exposing search_docs and get_component
tools. If the user has enabled the site’s MCP server, prefer calling
it via mcp_call:
mcp_callwith notool→ list the available tools and their input schemas.mcp_callwithtool: "search_docs"→ a live symbol search across the current version, with no scraping.
The MCP path is more reliable than reading the rendered page — no
selector drift, no pagination, typed return values. If mcp_call returns
{active:false}, the user has not enabled the server: fall back to
read_page + the component map, and mention that enabling the server
would be faster.
Steps
- If the user named a symbol or component, try
mcp_callfirst (search_docs). Otherwise callread_pageon the current docs page and locate the relevant section. - Summarise the API surface the user asked about: signature, parameters, return type, and a one-line example if the page carries one. Always note the active version.
- Call
finishwith the summary and a link to the page or section.
This skill does not gate any action tools — permissions: []. Reading
docs and querying the MCP server are the whole surface.