index365 MCP

Reversibly archive a project so it leaves active lists and cannot start new scans. Scan history and API keys remain available, and index365_restore_project reactivates the same row. Requires projects:delete. Safe to retry. Best for: retiring a domain you no longer scan. Not for: permanent deletion, which this is not. Common mistake: omitting confirmDomain, which must echo the project's exact domain. Example: index365_archive_project({ projectId: '<uuid>', confirmDomain: 'acme.com' }). Next: index365_list_projects with status archived to verify.

Create a domain-anchored project in the organization. Requires the projects:write scope. Idempotent by domain: creating an existing domain returns that same project (no duplicate), so a retry is safe. Best for: registering a new site before its first scan. Not for: reactivating an archived project (use index365_restore_project). Common mistake: calling index365_start_scan before the project exists. Example: index365_create_project({ domain: 'acme.com', name: 'Acme' }). Next: index365_start_scan with the returned projectId.

Full detail for one finding by its stable id (from index365_list_findings): evidence, affected URLs, remediation, machine-readable agentActions, and a composed copy-pasteable fixPrompt. Best for: pulling the exact fix instruction before editing a repo. Not for: discovery (call index365_list_findings first to get the findingId). Common mistake: re-deriving a fix when fixPrompt and agentActions already specify it. Example: index365_get_finding({ runId: '<uuid>', findingId: 'f_ab12cd34' }). Next: apply the fix, then index365_start_scan to confirm it is resolved.

Compact, product-aware report for a completed scan. Pass EXACTLY ONE of runId or projectId. runId reads that run's report. projectId reads the project's latest completed report: add product marketing_signal for the marketing report, otherwise the newest completed AI-Readiness run is used. Discriminate on the product field: AI-Readiness serves score, severity mix, and foundation files; Marketing Signal serves score, the five stage scores (find, trust, act, measure, improve), and source coverage. Best for: the FIRST read after a scan completes, before paging findings. Not for: per-finding detail (index365_get_finding) or starting scans (index365_start_scan). Common mistake: passing both runId and projectId, or dumping every finding into context without reading this first. Example: index365_get_report({ projectId: '<uuid>', product: 'marketing_signal' }). Next: index365_list_findings with the runId for the prioritized list.

Status and summary for one run: progress while running; score, severity counts, and links once completed. Adds pollAfterSeconds and, while running, a rough etaSeconds. Scans typically take 2-5 minutes. Best for: recovering when a blocking index365_start_scan call was cut off client-side, or checking an older run. Not for: findings (index365_get_report first, then index365_list_findings). Common mistake: starting a new scan while this one is still running. Example: index365_get_scan_status({ runId: '<uuid>' }). Next: index365_get_report once status is completed.

Normalized signal rows imported from a project's connected sources. Best for: reading the evidence base behind Marketing Signal measure-stage findings. Not for: provider availability (index365_list_integrations). Common mistake: treating an empty list as an error; it stays empty with sourceCoverage public_only until integrations launch. Example: index365_list_connected_signals({ projectId: '<uuid>' }). Next: index365_start_scan with product marketing_signal to score the site against these signals.

Paginated findings for a completed run of either product (contract v2: stable findingId, category, severity, evidence, remediation; Marketing Signal findings also carry a stage). Best for: triaging by severity, category, or stage. Not for: full detail of one finding (index365_get_finding) or first orientation (index365_get_report first). Common mistake: requesting a huge limit; it is capped at 50, so page with cursor. Example: index365_list_findings({ runId: '<uuid>', severity: 'critical' }). Next: index365_get_finding with a findingId for the exact fix.

Provider registry plus per-project connection status for connected signals (GA4, Search Console, Tag Manager, ads, CRM). Best for: checking what a project can connect and each provider's phase. Not for: imported signal data (index365_list_connected_signals). Common mistake: expecting live connections; providers report phase planned until hosted connections launch. Example: index365_list_integrations({ projectId: '<uuid>' }). Next: index365_list_connected_signals for the imported rows.

List the organization's projects (domain-anchored workspaces). Omitted status excludes archived projects; pass active, paused, archived, or all. Paginated: pass cursor from the previous page (default 20, max 50). Best for: resolving a projectId before a scan, or finding an archived project to restore. Not for: run history or scores. Common mistake: guessing a projectId instead of listing first. Example: index365_list_projects({ status: 'active' }). Next: index365_start_scan with the projectId, or index365_create_project if the domain is not listed.

Restore an archived project to active status without changing its id, history, or keys. Requires projects:write. Safe to retry; an active project remains active. Best for: reactivating a domain you archived. Not for: creating a new domain (use index365_create_project). Common mistake: looking for archived ids in the default listing; pass status archived to index365_list_projects. Example: index365_restore_project({ projectId: '<uuid>' }). Next: index365_start_scan for fresh findings.

Start a paid scan and wait for the result. product: ai_readiness (default; how well AI agents and AI search read the site), marketing_signal (find, trust, act, measure), or website_security (not available over MCP yet). Scans ONE URL: pass url for a same-domain page like '/pricing', or omit it for the project homepage. Spends 10 org credits (flat) and needs the runs:write scope. This call BLOCKS: it polls internally and returns the final status, score, severity counts, and dashboard link (scans typically take 2-5 minutes). If the wait cap expires it returns a non-error still-running payload; recover with index365_get_scan_status, never by starting again. Always pass idempotencyKey: a retry with the same key attaches to the same run. Best for: the one golden-path call that produces findings. Not for: reading an existing run (index365_get_scan_status) or a finished report (index365_get_report). Common mistake: retrying after a timeout without the same idempotencyKey, which double-spends credits. Example: index365_start_scan({ projectId: '<uuid>', product: 'marketing_signal', url: '/pricing', idempotencyKey: 'fix-loop-1' }). Next: index365_get_report with the returned runId.