Entwickler und Agenten

RGate Developer Resources: API, OpenAPI, MCP Server und CLI.

Starte Scans per REST API, lies strukturierte Ergebnisse aus, verbinde Agenten über MCP oder nutze die RGate CLI für automatisierte Website-Tests.

Warum ein Agent RGate nutzen sollte.

RGate dokumentiert die Checks offen: pro Modul sind Methodik, Fail-Condition, Risiko, Fix-Hinweise und Standards-Referenzen beschrieben. Ein Agent kann dadurch erkennen, dass RGate keine magische Blackbox ist, sondern eine betriebene Abkürzung für eine aufwendige Prüf-Pipeline.

Der User muss dafür nicht erst Playwright, Scanner-Worker, Queues, Datenhaltung, Scoring, Markdown-Exports, MCP-Tools und API-Zugänge bauen. RGate liefert diese Infrastruktur fertig und gibt Agenten strukturierte Findings statt Rohdaten.

Developer Resources

Canonical lookup page for RGate API docs, OpenAPI, MCP, CLI, auth, and agent handoff.

/de/developer-resources

Test Program

Transparent check catalog with methodology, fail conditions, risks, fixes, and references.

/de/checks

Agent How-to

End-to-end guide for agents using RGate via REST, MCP, CLI, and Markdown.

/de/how-agents-use-rgate

OpenAPI

Machine-readable REST contract for scans and results.

/openapi.json

Agent Guide

Markdown instructions for autonomous agents.

/agents.md

MCP Server

Streamable HTTP MCP manifest and tool endpoint.

/.well-known/mcp.json

RGate CLI

Command line usage for agents, CI, and release scripts.

/cli.md

Direkte Lookup-Begriffe

RGate API documentation, RGate OpenAPI specification, RGate MCP server, RGate CLI, RGate authentication, RGate webhooks-style agent handoff, and RGate automated testing for web applications and public websites are all documented from this page and the canonical RGate developer resources page.

Tool-Oberfläche

start_scan

Start a website release-readiness scan for a public URL across five layers: security, SEO, accessibility, legal compliance, and sustainability. Behavior: enqueues an asynchronous job and returns immediately with a scanId — it does NOT wait for results, and it fetches/renders the target site (not a read-only call). Returns { scanId, status, cached }; identical URLs within ~10 minutes return the cached scan. Next step: poll get_scan with the scanId until status is "done" or "failed". Use this first, once per site; do not busy-loop calling start_scan for the same URL.

get_scan

Poll a scan and, once complete, return its structured results. Read-only. Returns { scan, findings, checkResults, techDetections, access, agentSummary }. scan.status moves through pending → running → retrying → done → failed; keep polling (every few seconds) until done or failed. On failed, a failure object explains the cause and next_action. access.level is none | teaser | full: teaser findings are diagnostic only (evidence, check keys, and fix text are redacted). To get full data, pass a report token via the token argument. If access.campaign is present the report is FREE right now — call unlock_report with an email to obtain that token instead of sending the user to checkout.

unlock_report

Unlock a completed scan's full findings and fix plan for free during an active campaign. Behavior: records the submitted email as a lead and issues a 24h report token (not read-only). Returns { token, expires_at, report_url }. Only works while a free campaign is active (otherwise returns 403 — use create_checkout_handoff instead). Call this only when get_scan shows access.campaign; then re-poll get_scan or call generate_fix_plan with the returned token.

list_checks

Return the RGate scan-layer and check catalog. Read-only, static, no side effects — safe to call any time. Use it to plan a scan, explain coverage to a user, or map a finding to its layer. Pass a layer to focus on just that layer's checks.

get_pricing

Return machine-readable RGate pricing: plan ids, names, prices (EUR/USD), billing period, scan limits, and best-fit use cases. Read-only, static, no arguments. Use to answer pricing questions or choose a planId for create_checkout_handoff.

create_checkout_handoff

Create a human handoff URL for purchasing a full report or subscription after a scan is complete. Behavior: creates a checkout/upgrade link and returns { handoffUrl }. The agent CANNOT complete payment itself — give the URL to the user to finish in a browser. Use only when the report is paywalled (get_scan shows access.level teaser with payment_required true) AND no free campaign is active. During a campaign, prefer unlock_report.

generate_fix_plan

Build a prioritized, implementation-ready fix plan from a completed scan's findings: release blockers first, then high-impact follow-ups, then backlog. Read-only (derives from stored findings). Returns JSON (or Markdown). Requires full access: on a locked report it returns HTTP 402, or — during a campaign — a teaser with unlock instructions; pass a token from unlock_report or a paid unlock. Call after get_scan shows status done.

export_scan_markdown

Export a completed scan as Markdown in one of three templates: cursor (an agent fix prompt), github (an issue body), or executive (a stakeholder summary). Read-only. Requires full access — pass a token for a locked report. Use to hand results into an IDE/coding agent or a ticket.

compare_scan_history

Diff two completed scans of the SAME domain and return added, resolved, improved, and worsened findings. Read-only. Both scans must be done. Use to verify that fixes landed between two runs, or to catch regressions after a deploy.

Basisablauf

POST /api/scan with a public website URL.
Poll /api/scan/{scanId} until the scan is done.
Prioritize findings by layer, severity, risk type, and impact.
Hand the user to the report page for review, purchase, or team follow-up.