20+ tools, one MCP server. The agent reads, updates and comments on every finding, surfaces similar issues, and pulls project-specific rules from Cybe before generating a single line of code.
list_vulnerabilities_sastREADupdate_vulnerabilityUPDATEget_business_logic_contextCONTEXTget_similar_vulnerabilitiesSIMILARSecurity findings used to live in a dashboard nobody opened.
The agent now opens it on every prompt and acts on what it sees.
Every CVE on your roadmap is one chat message from being closed.
The MCP doesn't replace your scanners, it gives the agent the same view your security team works from, plus the write access to act on it, plus the project-specific context to write secure code from the start.
Paginated lists with rich filters (severity, status, priority, language, branch, packageType) plus the full record per finding, snippet, file, line, package tree, remediation hint. One consistent shape across every scanner so the agent reads what your security team reads, in the same call.
To verify → Confirmed → Resolved · Not exploitable · Proposed not exploitable · Ignored. Update priority, attach a comment, find a similar batch with one call and apply the same status to the lot. Every action lands in the audit trail signed by the agent.
Before the agent writes a payment endpoint or auth flow, it asks for the rules your project enforces. Cybe crawls the repo, builds a code knowledge graph and extracts tenant scope, refund caps, idempotency keys and audit-trail conventions, shipped back as a system prompt the agent inlines before writing the diff.
Every Cybe tool call follows the same three-step path. The agent doesn't orchestrate, it asks, the MCP routes, the answer lands in context.
The agent picks the right tool from the 18 we expose, each with a typed schema its planner can reason about. Filters and projectId default from the environment so prompts stay terse.
Vulnerability calls hit the platform's REST API behind a refreshing PAT exchange. Business-logic calls hit Cybe, which spins up an incremental knowledge-graph crawl scoped to the requested branch. Region pinning (EU or US) is enforced at the boundary.
Findings return with the location data the agent needs to patch in place. Status updates echo back the audit-trail entry. Business-logic responses arrive as a structured system prompt, ready to inline before code generation.
Two views of the same prompt, "add a payment endpoint". On the left, what a generic AI assistant produces with no project context. On the right, what the same agent produces after one call to get_business_logic_context.
function refund(orderId, amount) {
if (req.user.id === order.userId) {
db.orders.refund(orderId, amount);
}
}Boilerplate Express handler. Hardcoded amount, no idempotency key, no audit log, no tenant scope. Lints clean, passes basic tests, ships a tenant cross-talk + double-charge bug to staging.
syntax: cleanasync function refund(orderId, amount, req) {
const key = req.headers['idempotency-key'];
if (!key) return res.status(400).end();
const order = await db.orders.findById(orderId, {
where: { companyId: req.companyId },
});
if (!order) return res.status(404).end();
const cap = await stripe.refunds.create({
payment_intent: order.intent,
amount,
});
await audit.log({
actor: req.user.id,
amount,
captureId: cap.id,
});
return res.json({ ok: true });
}Cybe returned three project rules: scope every payment by req.companyId, require an Idempotency-Key header, log the operator + amount + capture-id to the audit table. The agent inlines them before writing the handler, the first draft already meets the policy.
Each scanner exposes a list_… tool to walk through findings and a get_… tool to drill into a single record. SCA adds list_sca_packages for the dependency tree.
Cybe MCP is a thin wrapper around CybeDefend's REST surface, your repo never moves, your model weights stay frozen, and every call carries the agent's identity into the audit trail.
Pick the region for both the MCP runtime and the platform backend with REGION or API_BASE. The default is single-region pinning; cross-region traffic only happens when you explicitly opt in. SOC 2 Type II controls are enforced on either side.
Model weights are frozen for inference only. We don't fine-tune, RLHF or evaluate on your repos, the contract you sign reflects this and the audit log proves it. Cybe's knowledge graph is per-tenant and ephemeral.
The MCP itself stores nothing, every call is a thin REST request that streams the answer back to the agent. The PAT-to-Bearer exchange happens inline; the agent's identity and timestamps land in the platform's audit trail for every read or write.
Read every finding across SAST · SCA · IaC · CI/CD · Secrets · Container with full filters (severity, status, priority, language, branch, packageType). Drive the full status lifecycle: To verify → Confirmed → Resolved · Not exploitable · Proposed not exploitable · Ignored. Update priority, leave comments, find similar findings, walk the dependency tree, get a project overview. And on top of that, fetch project-specific business-logic rules from Cybe before generating new code. 20+ tools, all typed, all schema-discovered, with new ones rolling out as the platform grows.
It crawls the repo, builds a code knowledge graph (routes, services, owners, framework conventions, data-flow boundaries), and extracts the rules that govern how the codebase actually works, tenant scope, refund caps, idempotency keys, audit-trail completeness, role checks. Today the rules are mined and stored per project, scoped to the requested branch. Per-account refinement (org-wide rules that survive across projects) is rolling out next, with finer-grained personalisation still.
Cursor, Claude Desktop, VS Code Copilot Chat (via .vscode/mcp.json), JetBrains, Gemini CLI, Cline, Continue, Zed, plus any client that speaks the MCP protocol. The same MCP server (npx @cybedefend/mcp-server or a Docker image) connects to all of them, one install, every surface.
No. The MCP itself is a thin wrapper around the CybeDefend REST API, every call is a request, the answer streams back, nothing persists locally. Findings, statuses and audit history live in your CybeDefend tenant. Source files are processed in memory by Cybe when you call get_business_logic_context, never persisted at rest by the MCP.
Set REGION="eu" or REGION="us" (or pin a specific API_BASE) and every call lands in the corresponding region. Cross-region traffic only happens if you explicitly enable it. Both regions are SOC 2 Type II audited and the EU region maintains GDPR-compliant data flows.
Yes, update_vulnerability lets the agent move a finding through the full status lifecycle, set priority and attach a comment. We recommend pairing it with get_similar_vulnerabilities so the agent can propose a batch action (mark a class of false-positives as not_exploitable in one shot, for instance), with each action stamped to the agent's identity for the audit trail.
No credit card. No setup call. Pick your agent, paste the command, and Cybe enforces your rules from the very next prompt.
claude mcp add cybedefend --transport http https://mcp-eu.cybedefend.com/mcpHosted MCP, no install. Just register the URL with your agent.