Rebuild MCP documentation from structured runtime and client data

[webrdaniel]

Note

This issue was AI-generated based on an AI analysis of Apify’s agent-facing contracts.

Current problem

The generated machine-readable MCP documentation repeats authentication and client sections, misplaces expanded tab content, introduces account requirements before anonymous discovery, and retains an expired SSE migration notice. It also describes tool behavior that no longer matches the released MCP server. An agent reading the Markdown can follow a longer or incorrect setup path even though the human page appears usable.

Why this reduces adoption and usage

• The repeated and misplaced content consumes model context before an agent reaches a working configuration.
• Stale tool and transport guidance causes failed setup attempts and unnecessary recovery steps.
• Contradictory anonymous-versus-authenticated ordering increases the largest existing Configurator funnel drop before users copy a configuration.
• Agents are less likely to treat Apify documentation as authoritative when the machine-readable version differs from the human page.

Desired state

The HTML and machine-readable MCP pages are anonymous-first, OAuth-first for execution, structurally valid, and generated from current runtime/client metadata.

Acceptance criteria

• Order the journey: anonymous discovery, hosted OAuth, client-specific setup, bearer fallback, local stdio, advanced selection.
• Remove the expired SSE notice and retired tool behavior.
• Define shared authentication prose once and generate only client-specific deltas inside tabs.
• Generate tool names/defaults from the released MCP package.
• Snapshot-test HTML and .md output for headings, tab expansion, lists, fences, and duplicate sections.

Priority: P0. Estimated effort: M.