MCP Client (Universal Vendor Pull)

At a glance

Vendor	Vendor-agnostic. Configure one Draxis integration per remote MCP server: https://mcp.crowdstrike.com, https://mcp.okta.com, your own internal server, anything that speaks MCP over Streamable HTTP.
Source type	mcp_client
Vendor ID (slug)	mcp-client
Base URL	The remote MCP server URL you paste in the setup form.
Auth method	OAuth 2.1 + PKCE (RFC 7636). Dynamic Client Registration (RFC 7591) when the remote supports it; static credentials fallback when it doesn't.
Schedule default	daily. Configurable to hourly, weekly, or manual.
What it produces	KRI value rows in your Risk Register. Tools that return structured data write to specific KRI signals; tools whose output is unstructured route to the AI Drop Zone extractor for signal mining.
What it costs	One bounded tool call per mapped tool per run (default cap: 50 calls per run, tunable). Paginated tools count each page against the cap. AI mapping at discovery time and AI extraction on drift events bill against your Anthropic key.
Availability	New in 2026.05.

What problem this solves

The old model is one Draxis connector per vendor. Every vendor's API shape is different, every schema change breaks something, and shipping a new vendor takes engineering time. Two things changed in 2026: the major security vendors started shipping official MCP servers, and our design-partner conversations showed customers actively prefer that path. The MCP Client connector is the bet on that direction. Configure it once per vendor, the AI does the mapping, the same connector code handles every vendor.

The second problem it solves is drift. Wiz changes its data shape almost weekly. A vendor connector hand-coded against the schema-of-the-week breaks the moment Wiz ships a rename. The MCP Client connector pairs every deterministic JSONPath extraction with an AI fallback: when extraction misses, the response routes through the AI Drop Zone, the value lands anyway, and the AI proposes a corrected mapping for the next run.

How it differs from the AI Drop Zone

Both connectors use the same AI extraction pipeline, but the direction is opposite. The AI Drop Zone is push: a user pastes, uploads, posts a webhook, or calls the submit_dropzone_artifact MCP tool. The MCP Client connector is pull: Draxis schedules outbound calls to the remote MCP server and ingests what comes back. The Drop Zone is for the long tail (one-off scanners, vendor SOC 2s, auditor PDFs); the MCP Client is for the actively-pulled vendors that previously needed a bespoke native connector.

Setup steps

1. Open Settings → Integrations → Add Integration.
2. Pick MCP Client (Universal Vendor Pull) as the Source Type.
3. Give the integration a Display Name. Pick something specific (e.g. “Okta via MCP”, “Internal SOC MCP”) so the audit trail is scannable.
4. Paste the remote MCP server URL.
5. Pick a vendor hint from the dropdown. The hint biases the AI mapper toward that vendor's known KRI signals at discovery time. Use a known vendor when Draxis already has a native connector for that vendor (the dropdown lists every native connector); use Other with a free-text label for anything else.
6. Adjust the cost ceiling (default 50 tool calls per run) and the freshness window (default 60 minutes) if you want different defaults for this integration.
7. Click Save Integration. The row appears with an amber “OAuth not connected” banner.
8. Click Connect. A new tab opens to the vendor's authorize page. Sign in, grant the requested scopes. The callback returns you to Draxis with the integration authorized.
9. Click Re-discover on the integration's detail panel. The AI mapper proposes a tool-to-KRI mapping for every tool the remote advertises. High-confidence proposals auto-accept under your tenant's autonomy band; the rest queue for review.
10. Review the pending proposals. Each row shows the proposed JSONPath, value transform (count, sum, bool, unique_count), pagination shape, and AI confidence. Accept, reject, or edit before accepting. Add an optional note explaining your decision: it feeds back into the AI training signal for future proposals.
11. Wait for the first scheduled run, or click Run Now on the integration card.

Authentication

Dynamic Client Registration (recommended)

When the remote MCP server advertises a registration_endpoint in its /.well-known/oauth-authorization-server document, Draxis registers itself automatically via RFC 7591 the first time you click Connect. No client_id or client_secret to copy by hand.

Static credentials (fallback)

For MCP servers that do not support Dynamic Client Registration, the integration detail panel exposes an Advanced toggle on the OAuth status card. Paste the Client ID and Client Secret your remote admin issued, click Save, then click Connect. The secret is encrypted at rest using the same AES-256-GCM key as every other connector credential.

Refresh rotation

Access tokens refresh automatically before expiry via the standard refresh_token grant. If the remote rotates the refresh token on each use (RFC 6749 recommendation), Draxis stores the new one. If a refresh fails (revoked, expired), the integration is marked disabled and surfaces in the UI with a Reauthorize prompt.

Discovery and AI mapping

Discovery runs on three triggers: when you save the integration for the first time, on a weekly schedule, and when the “Re-discover” button is clicked. Each run lists the remote's tools (deduped by SHA-256 of the input schema plus description), and for every tool whose signature is new or has changed, the AI mapper proposes one of:

• KRI mapping. The tool returns structured data and the mapper can pull a numeric value out of it. The proposal includes the canonical KRI signal slug, request arguments, a JSONPath expression, a value transform (count, sum, bool, unique_count, or identity), and any pagination details.
• Artifact (route to extractor). The tool returns unstructured data (incident bodies, free-form findings, narrative reports). On each run the response is persisted as an AI Drop Zone artifact and mined for signals through the same extractor pipeline as paste / upload / webhook intake.
• Skip. The mapper cannot find a useful KRI link, or the tool advertises itself as writeable (annotations.readOnlyHint == false). Tools that mutate vendor state are never invoked by Draxis in v1.

Every proposal flows through your tenant's autonomy gate (Settings → AI Autonomy → mcp_tool_mapping). High-confidence proposals with non-empty reasoning auto-accept and immediately become active mappings; below the threshold they queue for review; below the dismiss floor they're logged but never reach the queue. Every accept, reject, and auto-decision is recorded in ai_proposal_outcome so the AI gets ground-truth feedback over time.

Pagination

Most list_* tools paginate (Okta lists users by limit and after-cursor; CrowdStrike pages detections by offset; Wiz uses opaque cursors). The AI mapper declares the pagination shape at discovery time: cursor, offset, page number, or none. At execution time the connector walks pages until the cursor returns null, the page returns empty, an explicit has_more=false flag fires, or the per-tool page cap is reached (default 20, configurable on the mapping).

Each page is recorded as its own row in the tool-call log so the cost cap stays honest: a paginated tool that fans out to 8 pages spends 8 calls of the per-run budget, not 1.

Self-healing drift recovery

Vendor APIs drift. When a deterministic JSONPath misses (because Wiz renamed a field or CrowdStrike added a layer of nesting), Draxis does not let the KRI go stale. Instead, the raw response routes through the AI Drop Zone extractor as if it were any other artifact, the AI re-derives the value, and a corrected mapping is proposed for the next run.

Three things make this safe: the drift event is logged explicitly with status='drift_recovered' in the tool-call audit row; the mapping's drift_recovery_count bumps each time so unstable vendors are visible at a glance; and the re-proposed mapping flows through the same autonomy gate as the original, so high-confidence fixes auto-accept and the deterministic path resumes on the run after that.

For tools where you don't want the AI Drop Zone fallback to fire (typically tools whose responses include user PII or raw incident bodies you don't want forwarded to Anthropic), flip the route to extractor on drift toggle off in the mapping review. Drift on that tool then surfaces in the review queue instead of auto-recovering.

Cost and safety

• Per-integration call cap. Default 50 tool calls per scheduled run. Paginated tools count each page. Configurable per integration; raise it for chatty vendors, lower it for cost-sensitive ones.
• Freshness gate. If the first page of a tool's response has the same SHA-256 as the previous successful run and the freshness window (default 60 minutes) hasn't expired, the connector reuses the prior result instead of refetching pages 2..N. Meaningful saver on daily polls of large datasets.
• Source priority. Each integration carries a numeric priority (lower wins). MCP Client rows default to 40; native vendor connectors default to 50. If both a native connector and an MCP-via-the-same-vendor integration write to the same KRI, the MCP path wins by default. Flip the priority on either source to change the order.
• Soft-drift telemetry. If a tool's most recent run returned less than 50% of the trailing 30-day median item count, the inventory shows a possible drift indicator. Not auto-recovery, just a heads-up so analysts can spot quiet failures (e.g. a vendor silently reduced what one cursor returns) the deterministic path wouldn't catch.
• No vendor writes. Even if the remote exposes mutation tools (disable user, isolate host), v1 never invokes them. Read-only by construction.
• Outbound SSRF guard. Every URL the connector touches passes the same hostname-resolution check the rest of the Draxis runner uses. Loopback, RFC1918, link-local, and cloud-metadata IP ranges are blocked at egress.

How it appears in the rest of Draxis

• KRI Board. KRIs fed by an MCP Client row show a small via MCP badge next to the source chip. When the same canonical signal is also fed by a native connector, the KRI card surfaces an also: <other source name> hint so analysts know both are running.
• Integration card. The expanded panel under each MCP Client row shows OAuth status with a Reauthorize button, a Re-discover control, the AI mapping review queue, the tool inventory with drift badges, and a tool-call log filterable by failed / drift events.
• AI Lineage. Every accept / reject / auto-* decision lands in ai_proposal_outcome under the mcp_tool_mapping proposal type, alongside extraction, scoring, control effectiveness, and the other AI flows.
• Audit log. Every tool invocation produces an integration_run row with structured results; per-page detail is in mcp_client_tool_call.

Coexistence with native connectors

Native connectors don't go away on day one. A tenant can run native Okta and Okta-via-MCP side-by-side: both schedule normally, both write KRIs, and source priority resolves any direct conflict on the same signal (default: MCP wins). Once an MCP integration has been stable for two weeks, the UI surfaces a prompt to decommission the native one; the swap is reversible, and the native connector code stays in the registry until a future cleanup release.

Quirks

• Two cursors are rare but real. Some APIs paginate with forward and backward cursors at the same time, or per-shard. v1 supports a single cursor field per tool. Tools that need multi-cursor pagination should be set to mapping_kind='artifact' at the review step so the extractor handles the full response shape.
• OAuth-incompatible servers. A handful of internal MCP servers ship with bearer tokens, signed headers, or mTLS instead of OAuth. The static credentials path covers most bearer cases; the rest are an open item we'll handle case-by-case as they show up.
• Data residency. Tools routed to the extractor send their responses to Anthropic's US-region API. If a tenant requires no-egress-to-US, disable the extractor fallback at the mapping level (drift on those tools surfaces as a manual review item instead of auto-recovering).
• Tool changes mid-loop. If a paginated tool changes shape between page 1 and page 5, the connector terminates the loop early, routes the accumulated response to the extractor, and re-proposes. The KRI value will land but it reflects a partial dataset for that run. The corrected mapping kicks in next run.

Troubleshooting

• Connect button fails with “remote MCP server did not return a valid oauth-authorization-server document”. The remote does not expose RFC 8414 discovery documents at the expected paths. Confirm the URL points at the MCP root (not a deeper path), then try the static-credentials fallback under Advanced.
• OAuth callback shows “Token exchange failed”. Most often a clock-skew issue on the Draxis host (PKCE state expires) or a redirect_uri mismatch. The error message includes the remote's response; check the host clock first, then reach out to the remote admin if their token endpoint is rejecting the redirect.
• Discovery returns 0 proposals. The remote exposes tools that don't fit the canonical catalog and the vendor hint didn't bias toward any of them. Either pick a more specific vendor hint, or set mapping_kind='artifact' on the relevant tools so the extractor mines their output.
• KRI not appearing after run. Check the tool-call log for the tool in question. status='drift_recovered' means the value landed via the extractor and a corrected mapping is queued; status='extraction_failed' means the deterministic path missed and the extractor route was disabled.
• Run fails with “integration not authorized (no refresh token)”. OAuth has not completed, or the refresh token was rotated and the old one is in cache. Click Reconnect on the OAuth status card.
• Vendor changed something and the KRI is wrong. Check the tool-call log for drift indicators. If drift_recovery_count is climbing, look at the AI mapping review queue: drift re-proposals carry the original mapping plus a sample of the failing response so you can validate the AI's fix.
• Still stuck? Open a support ticket with the integration ID (from the URL bar after you click Edit) and the run ID from the integration_run history.

Related

The MCP Client connector can be invoked from the other direction too: tools like Claude Cowork, Claude Code, Cursor, and ChatGPT Connectors can push evidence into Draxis via the submit_dropzone_artifact MCP tool exposed on the Draxis side. See the Claude Desktop, Claude Code, ChatGPT Connectors, Cursor, and VSCode + Copilot pages for the inbound setup; this page is the outbound counterpart.