MCP server | Cefense docs

Cefense runs a remote MCP server at https://cefense.com/mcp. An MCP client connects to it with that URL and signs in through the browser with your Cefense account. There is nothing to install and no key to paste.

Connect a client

Every client takes the same URL. These add it once for your user, so every project you open has it, and the first call opens the Cefense sign-in page in your browser. To keep it to one repository instead, use your client's project scope: --scope project in Claude Code and Gemini CLI, .cursor/mcp.json in Cursor, .vscode/mcp.json in VS Code.

claude mcp add --scope user --transport http cefense https://cefense.com/mcp
# then run /mcp inside Claude Code and choose cefense to sign in

Chat apps

App	Where to add it
Claude, on the web or desktop	Settings, then Connectors, then Add custom connector. Paste `https://cefense.com/mcp`.
ChatGPT	Settings, then Connectors. Turn on developer mode under Advanced, then create a connector with `https://cefense.com/mcp`. Developer mode depends on your ChatGPT plan.

Any other client that can reach a remote MCP server over HTTP and sign in with OAuth works the same way: give it the URL. You never paste a key.

Signing in

The first call opens a Cefense sign-in page in the browser. Approve it and the client keeps the access it was given, scoped to your account. It sees the organizations you belong to with the role you hold in each, so a member gets the same refusals over MCP as in the CLI. When you belong to more than one organization, every tool takes an organization slug from list_organizations.

Tools

Tool	What it does
`list_organizations`	The organizations you belong to, with your role and the slug the other tools take.
`list_repositories`	Connected repositories, each with its `githubRepoId` and a summary of its latest scan.
`get_latest_scan`	The newest scan of a repository: status, progress, finding count, coverage, error.
`list_branches`	Each branch with its latest scan.
`list_commits`	Scanned commits on a branch, with what each one introduced and resolved.
`list_findings`	The findings of the latest scan, or of a named scan, one line each.
`get_finding`	One finding in full: code, evidence, reachability, data flow, remediation, matched research.
`get_fix`	The patch prepared for a finding, its diff, and the pull request if one was opened.
`get_proof`	The proof run against a patch: status, verdict, and the checks behind it.
`list_audit_events`	The organization's activity log, newest first.
`get_plan`	The plan, how much of the scan allowance is used, and the limits.
`start_scan`	Rescan a repository, optionally on a branch. Spends scan allowance.
`triage_finding`	Record `false_positive`, `accepted_risk`, or `open` on a finding.
`generate_fix`	Ask Cefense to prepare a patch. Nothing is written to the repository.
`run_proof`	Run the finding's attack against the code before and after a prepared patch and settle a verdict.

The first eleven only read. The last four change state, and they are marked that way so the client asks you before running them.

What MCP does not do

It does not open or merge pull requests. Publish and merge a fix from the workspace or with cf fix publish and cf fix merge.
It does not connect or disconnect repositories, change billing, or change notification settings.
It does not read your working tree. Like the CLI, it reports on what was committed and scanned.

Finding ids belong to one scan

A rescan issues new finding ids. After start_scan, poll get_latest_scan until the scan is completed, failed, or cancelled, then call list_findings again rather than reusing ids from before. A stale id answers with a hint that says so.

Have a correction or need help?

Email the docs team