Detectify MCP Server

Closed beta — access required. The Detectify MCP Server is available to selected customers during a closed beta. You must have access enabled for your team before you can connect: contact your Detectify representative to request access. Until access is granted, the setup steps below will not let you authenticate. If you run into problems or need a configuration change for your setup, contact your Detectify representative.

The Detectify MCP Server is a remote Model Context Protocol server that exposes your Detectify data to AI coding agents and other MCP clients. Once connected, an agent can query your attack surface, assets, vulnerabilities, scan profiles, and compliance data directly through a set of read-only tools — for example, “list the most severe assets in my team” or “show the evidence for this finding”.

Access is authenticated per team with OAuth 2.1 + PKCE. You log in through your browser and pick the team the agent acts on behalf of.

Environment

Server URL: https://mcp.detectify.com/mcp
Public client ID: 5aaebbc4-eeca-4ede-a03e-682a495082f6

The server uses the Streamable HTTP transport. The client ID is a public OAuth client shared across every supported harness — there is no client secret.

Client setup

Before you start, confirm your Detectify representative has enabled MCP Server access for your team. Without it, the OAuth login will fail no matter which client you use.

Adding the server takes two steps: register it with your MCP client, then complete the OAuth login. The registration step differs per client, but the authentication step is the same OAuth 2.1 + PKCE flow in every case. Select your client below.

Claude Code

1. Register the server


claude mcp add --transport http detectify \
  https://mcp.detectify.com/mcp \
  --callback-port 54321 \
  --client-id=5aaebbc4-eeca-4ede-a03e-682a495082f6

2. Authenticate

Inside a Claude Code session run /mcp, pick detectify from the list, and choose Authenticate. Claude Code opens a browser where you log in to Detectify, consent, and pick your team.

Verify with /mcp — the server should show as connected.

Codex

1. Register the server


codex mcp add detectify \
  --url https://mcp.detectify.com/mcp \
  --oauth-client-id 5aaebbc4-eeca-4ede-a03e-682a495082f6

2. Pin the callback and scopes

Edit ~/.codex/config.toml: add the two mcp_oauth_callback_* keys at the root of the file (not inside any table), and add a scopes line to the [mcp_servers.detectify] block that codex mcp add just created.


mcp_oauth_callback_port = 54321
mcp_oauth_callback_url = "http://127.0.0.1:54321/"
 
[mcp_servers.detectify]
url = "https://mcp.detectify.com/mcp"
scopes = ["mcp:read", "offline_access"]
 
[mcp_servers.detectify.oauth]
client_id = "5aaebbc4-eeca-4ede-a03e-682a495082f6"

3. Authenticate


codex mcp login detectify

Codex opens a browser where you log in to Detectify, consent, and pick your team.

Copilot CLI

Copilot CLI supports a pre-registered public client, but its copilot mcp add command has no flag for the OAuth client ID or the callback port. Set those by editing ~/.copilot/mcp-config.json directly. Two fields are required beyond what the CLI writes:

oauthClientId — the pre-registered client (dynamic client registration is disabled).
auth.redirectPort — pins Copilot’s loopback callback port.

1. Register the server


copilot mcp add --transport http detectify https://mcp.detectify.com/mcp

2. Add the OAuth fields

Edit ~/.copilot/mcp-config.json and add oauthClientId and auth.redirectPort to the detectify entry:


{
  "mcpServers": {
    "detectify": {
      "type": "http",
      "url": "https://mcp.detectify.com/mcp",
      "oauthClientId": "5aaebbc4-eeca-4ede-a03e-682a495082f6",
      "auth": { "redirectPort": 54321 },
      "tools": ["*"]
    }
  }
}

Or, to add it non-destructively in one step (requires jq):


jq '.mcpServers.detectify = {
  "type":"http",
  "url":"https://mcp.detectify.com/mcp",
  "oauthClientId":"5aaebbc4-eeca-4ede-a03e-682a495082f6",
  "auth":{"redirectPort":54321},
  "tools":["*"]
}' ~/.copilot/mcp-config.json > /tmp/mcp.tmp && mv /tmp/mcp.tmp ~/.copilot/mcp-config.json

3. Authenticate

Start a Copilot CLI session; it detects the unauthenticated server and opens a browser (“Opening browser for detectify authentication…”). Complete the OAuth flow and pick your team. To confirm the port is pinned, check that the browser’s authorize URL contains redirect_uri=http://127.0.0.1:54321/ — a random port means auth.redirectPort was not applied.

Cursor

Cursor’s UI has no field for a pre-registered OAuth client ID — Settings → Customize → MCP only lets you add a server by name and URL. Add the auth block (client ID and scopes) by editing mcp.json directly.

1. Register the server

Edit ~/.cursor/mcp.json (create it if it doesn’t exist) and add the detectify entry:


{
  "mcpServers": {
    "detectify": {
      "url": "https://mcp.detectify.com/mcp",
      "auth": {
        "CLIENT_ID": "5aaebbc4-eeca-4ede-a03e-682a495082f6",
        "scopes": ["mcp:read", "offline_access"]
      }
    }
  }
}

The scopes field matters: if it’s omitted, Cursor discovers scopes from the authorization server’s project-wide metadata, which advertises an offline scope this client isn’t allowed to request — the request is then rejected with invalid_scope. Pinning scopes to the resource-level set above avoids that.

2. Authenticate

Restart Cursor (or reload the MCP config) so it picks up the file change. Open Settings → Customize → MCP — the detectify server appears with a Needs login button. Click it. Cursor opens a browser at one of two fixed redirect URLs (https://www.cursor.com/agents/mcp/oauth/callback for web/Agents, http://localhost:8787/callback for desktop) — both are already registered on this client. Complete the OAuth flow. The button changes to a connected indicator and the tool list populates.

OpenCode

The interactive opencode mcp add flow does not let you specify a pre-registered client ID or pin the redirect URI, so OAuth fails. Edit the config file directly instead.

1. Register the server

Add the following entry to ~/.config/opencode/opencode.json (merge mcp.detectify into your existing config if you already have one):


{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "detectify": {
      "type": "remote",
      "url": "https://mcp.detectify.com/mcp",
      "oauth": {
        "clientId": "5aaebbc4-eeca-4ede-a03e-682a495082f6",
        "redirectUri": "http://localhost:54321/callback"
      }
    }
  }
}

clientId is the pre-registered Detectify MCP client; redirectUri must match a redirect URI registered for that client.

2. Authenticate


opencode mcp auth detectify

OpenCode opens a browser for the OAuth flow and caches tokens.

VS Code

VS Code (v1.102+) has native MCP + OAuth support. Unlike the CLIs and Cursor, VS Code does not read the client ID from mcp.json — it prompts for it interactively on first authentication. Register the server with just transport and URL, then supply the pre-registered client ID when VS Code asks and leave the client secret blank (this is a public client).

1. Register the server

Create ~/Library/Application Support/Code/User/mcp.json (macOS user profile; on Windows/Linux use the equivalent Code/User/mcp.json, or add a workspace-scoped .vscode/mcp.json) and add the detectify entry:


{
  "servers": {
    "detectify": {
      "type": "http",
      "url": "https://mcp.detectify.com/mcp"
    }
  }
}

Alternatively, run MCP: Add Server from the Command Palette (⇧⌘P), choose HTTP, name it detectify, and paste the URL — VS Code writes the same entry for you.

2. Authenticate

Open the Command Palette (⇧⌘P) → MCP: List Servers → select detectify → Start Server. VS Code detects that the server needs auth and prompts for a Client ID — enter 5aaebbc4-eeca-4ede-a03e-682a495082f6 — followed by a Client Secret, which you leave blank. VS Code opens a browser where you log in to Detectify, consent, and pick your team. The MCP output shows success and the server shows as Running.

Verify with a tool call: open Copilot Chat in Agent mode, enable the detectify tools (🛠 icon), and prompt e.g. “Using the detectify tools, what team am I connected to?”. A successful get_current_team response confirms the connection end-to-end.

Troubleshooting

You only see a login page at https://detectify.com/oauth2/consent?consent_challenge=XYZ… — do a hard reload of the /oauth2 page (⇧⌘R).
Browser never opens / callback times out — confirm nothing else is bound to the loopback port the agent uses (54321 for Claude Code, Codex, Copilot CLI, and OpenCode). Because these share port 54321, don’t run two OAuth flows at the same time.
Codex login hangs after clicking Allow — you likely clicked the first of two authorization URLs Codex printed. Confirm scopes is set on the detectify entry in ~/.codex/config.toml so only one URL is printed, then re-run codex mcp login detectify.
Copilot CLI callback times out — check the browser’s authorize URL shows redirect_uri=http://127.0.0.1:54321/. A random port means auth.redirectPort wasn’t applied (config not saved, or the field dropped in a newer Copilot build). If a previous attempt cached a bad redirect, clear ~/.copilot/mcp-oauth-config/ and retry.
Cursor rejects the request with invalid_scope — the auth.scopes field is missing from the detectify entry in ~/.cursor/mcp.json.

Available tools

The server exposes read-only tools grouped by area.

Team and account

Tool	What it’s for
`get_current_team`	Which Detectify team you’re acting as (name and team token).
`list_users`	Team members with their role and last-login time.

Asset inventory

Tool	What it’s for
`list_assets`	Flat list of assets (domains, IPs, ranges); scope to all, roots only, subassets only, or one root’s subassets.
`list_monitored_assets`	Assets with per-asset surface aggregates (IPs, countries, ASNs, ports, technologies).
`get_asset_details`	Full drill-down on one asset (surface state, named IPs, ports, DNS, technologies).
`list_asset_classifications`	What kind of thing each asset is (web app, API, redirect, 4xx/5xx) and which scanners cover it.
`list_most_severe_assets`	Assets ranked by the severity of vulnerabilities found on them (for prioritization).

Surface data (network / DNS / IP)

Tool	What it’s for
`list_ports`	Open ports across the surface, grouped by port number, with per-port asset/IP counts.
`list_port_details`	Row-level port records — which specific assets/IPs expose a given port.
`list_protocols`	Row-level service endpoints (scheme, service, transport, port, IP).
`list_protocols_by_scheme`	Protocols grouped by scheme (https, ssh, smtp…) with per-scheme counts.
`list_dns_queries`	DNS records observed for monitored assets (queried name, response, record types).
`list_ips_by_country`	IP footprint grouped by country, with per-country IP/domain/ASN counts.
`list_connectors`	Cloud/DNS connectors feeding Detectify (AWS, GCP, Cloudflare, etc.).

Technology inventory

Tool	What it’s for
`list_technologies`	Technologies detected across the surface, grouped by name, with per-tech asset counts.
`list_technology_versions`	Technologies rolled up by name and version.
`list_asset_technologies`	Row-level tech instances (tech × version × port × asset); find every asset running a given technology.

Vulnerabilities and findings

Tool	What it’s for
`list_vulnerabilities`	The team’s findings, with filtering (severity, status, asset, CVSS), sorting, and pagination.
`get_vulnerability_details`	Full evidence for one finding (request/response, CWE, OWASP, CVSS) — built for false-positive triage.
`get_vulnerability_severity_summary`	Team-wide severity breakdown counts (critical/high/medium/low + total).
`list_vulnerability_definitions`	Catalog of what Detectify can detect (is a given CVE or class covered?).

Scan profiles and scan results

Tool	What it’s for
`list_application_scan_profiles`	Application Scanning profiles with each one’s latest scan status/result and next run.
`get_application_scan_history`	Scan-by-scan history for a single Application Scanning profile.
`list_api_scanning_profiles`	API Scanning profiles (target, rate limit, last scan, severity summary).
`get_api_scan_results`	Latest findings for one API Scanning profile (with CVE/CWE/CVSS detail).

PCI ASV Scanning

Tool	What it’s for
`list_asv_scan_profiles`	Approved Scanning Vendor (PCI external-scan) profiles.
`list_asv_reports`	Per-scan PCI compliance reports for one ASV profile (high/medium/low counts, pass/fail).

Policies and compliance breaches

Tool	What it’s for
`list_policies`	Security policies configured for the team (name, severity, trigger rules).
`list_policy_breaches`	Assets currently violating a policy (open compliance breaches).
`get_breaches_over_time`	Time-series of policy breaches by severity (for trend charts; max 30-day window).

WAF / scan interference

Tool	What it’s for
`list_waf_findings`	Requests blocked or altered by a WAF in front of a monitored asset (“is a WAF blocking our scans?”).
`get_waf_finding_details`	Full detail for one interference finding (risk, remediation, blocked request/response).