Open navigation menu
How to run a website privacy scan through MCP
Connect a compatible agent to CertScore.ai MCP Light, preserve the scan lifecycle, and report only evidence the completed public-safe bundle supports.
Canonical Light sequence
certscore_scan_site
→ certscore_get_scan_status while active
→ certscore_get_scan_bundle after terminal completionUse one public endpoint and three tools
CertScore.ai MCP Light is a no-account Streamable HTTP server at https://mcp.certscore.ai/mcp/light. A compatible agent discovers exactly three tools: certscore_scan_site, certscore_get_scan_status, and certscore_get_scan_bundle.
The small tool surface keeps the first run explicit: request or reuse a scan, check status only while work is active, then retrieve a bounded completed result. No API key, bearer token, browser login, or OAuth is required for the Light route.
Why the workflow is asynchronous
A browser-based website scan can outlive a normal interactive tool-call window. certscore_scan_site therefore returns a stable scanId with a new, reused, queued, running, or finalizing decision instead of holding the connection until every evidence lane finishes.
The client should retain that scanId, honor retryAfterSeconds, poll certscore_get_scan_status only for active work, and stop at a terminal status. It should call certscore_get_scan_bundle only after completed or completed_limited.
Keep preliminary and final evidence separate
A preConsentPreview is partial checkpoint context, not a finding, score, or final inventory. Final summaries should come from the completed bundle, which carries canonical public-safe findings, evidence references, coverage limitations, and report links where available.
A completed_limited or no-go result is still an observation with explicit limitations. It is not proof that a site is compliant, free of risk, or fully tested.
Reject Path evidence fails closed
CertScore describes Reject Path behavior only when an eligible scan confirms a deterministic refusal action and retains qualifying post-refusal evidence. Unsupported, unavailable, unconfirmed, stale, or unverifiable outcomes remain neutral and must not be turned into findings.
This boundary matters for agents: a missing Reject Path finding must never be rewritten as proof that rejection worked or failed.
Measure use without recording scan content
The hosted service measures bounded activation stages and tool outcomes using HMAC-derived opaque session or actor identifiers. It excludes prompts, target URLs, raw IP addresses, tokens, tool arguments, response bodies, and scan evidence from the growth funnel.
Consented landing-page analytics remain separate from essential MCP telemetry. The two systems are not joined into a cross-site user profile.
What the production benchmark established
In a 25-case sequential production benchmark completed on August 29, 2026, MCP initialization succeeded in 25 of 25 cases. The initial certscore_scan_site call had a measured p95 of 4.896 seconds and a maximum of 4.897 seconds, with no unexpected MCP failures.
That bounded benchmark validates the tested async path; it is not a service-level guarantee. Full scan completion still depended on the target and reached roughly 39 seconds in the tested cohort.