The Safeguard MCP Server is publicly available. MCP — Model Context Protocol — is a way for AI assistants to call external tools against a consistent contract. Our server exposes the Safeguard.sh platform as a set of MCP tools: scanning, classification, remediation, compliance mapping, and workflow execution. It works with Claude Desktop, claude.ai, Claude Code, ChatGPT, Cursor, Gemini, and Grok, and it is deployable as a hosted endpoint or self-hosted container.
Teams in private beta have been using the server for about six months. Public release means the tool surface is stable, the auth model is finalized, and the server is in scope for FedRAMP HIGH, IL7, and SOC 2 Type II. This post covers what the tools do, how auth works, and the patterns we see people actually use.
What tools does the MCP Server expose?
Answer first: 24 tools across five categories, all typed, all versioned.
The categories are scan, classify, reach, remediate, and comply. A few representative tools from each:
scan.repo,scan.image,scan.package— submit an artifact and get back a finding set.classify.artifact,classify.commit,classify.secret— run Eagle 3.0 on a specific input and get labels back.reach.paths,reach.is_reachable,reach.graph— pull reachability data for a finding or a dependency.remediate.plan,remediate.apply,remediate.resume— drive a Griffin 3.0 remediation run.comply.map,comply.evidence,comply.export— query Lino 2.0 for control mappings and evidence.
Every tool has a typed input schema and a typed output schema. The schemas are versioned and served from a well-known endpoint, so assistants can validate before calling. The server returns structured errors with stable codes — auth.unauthorized, quota.exceeded, input.invalid, policy.blocked, and a small list of others — rather than prose.
Two tools worth flagging because they come up most often in the transcripts we see. remediate.plan returns a griffin.plan/v3 document without applying any changes, which is what you want when you are using the assistant to reason about the fix before you take it. comply.evidence accepts a control identifier and a date range and returns the evidence items Lino has on file, which is how auditors' questions end up answered without anyone opening the web app.
How does the server fit with each of the supported clients?
Practically the same on all of them, with small ergonomic differences.
For Claude Desktop, Claude Code, and claude.ai, the server registers as a remote MCP endpoint. The user pastes a URL and a token, grants scopes, and the tools appear in the assistant. Claude Code can call remediate.apply in an agent loop; Claude Desktop typically sticks to remediate.plan and human-approved apply. There is no Safeguard-specific plugin — it is the standard MCP flow.
For Cursor, the MCP integration lives in the settings file. We ship a minimal .cursor/mcp.json snippet that developers can drop into a repo so the tool surface is available to everyone on the team.
{
"mcpServers": {
"safeguard": {
"url": "https://mcp.safeguard.sh/v1",
"transport": "http",
"auth": { "type": "bearer", "token": "$SG_MCP_TOKEN" }
}
}
}
For ChatGPT, Gemini, and Grok, the server is registered as an external tool source through each vendor's UI. We maintain a compatibility matrix in the docs for which tool-calling features each vendor supports (streaming, parallel calls, typed outputs) because the differences are real. The Safeguard tool surface is the same across all of them; the assistant's ability to chain tools is the variable.
For Grok specifically, which uses a slightly different auth shape, we publish an OAuth client configuration. The end-user flow is the same.
How does auth and scoping work?
The server issues scoped tokens. The default scopes are narrow, and the scopes that can mutate state require explicit grants.
Scopes are namespaced. A token with scan:read can call the scan.* tools. A token with remediate:apply can apply a Griffin plan to a repo. A token with comply:export can produce an audit package. The principle is that read-only tools (scan, classify, reach, comply-query) are in a default scope set, and anything that writes to a repo, a lockfile, or a compliance record requires an explicit grant and can be bound to a specific workspace.
Tokens are workspace-scoped. A single user can have multiple tokens, one per workspace, and enterprise customers typically create a dedicated "mcp-agent" service identity whose tokens are audited separately from human tokens. The server emits an MCP-call log for every tool invocation that includes the token ID, the workspace, the tool name, the input hash, the output hash, and the elapsed time. This log is the Lino evidence input for AI-assisted actions — it is how "who actually did that remediation" gets answered when the answer is "the assistant, on behalf of a human, with this token, at this time."
For Gov-region customers, tokens are issued against FedRAMP-HIGH-validated identity providers and the MCP-call log is streamed to the Sigstore transparency log as Lino evidence. The tool surface is the same; the audit trail is denser.
What patterns actually work in daily use?
Three that we see often and would point new customers at first.
Pattern one: developer-driven triage in the editor. The developer, working in Cursor or VS Code, hits a CVE in their dependency graph. They ask the assistant "is this reachable, and if so what is the smallest safe change?" The assistant calls reach.is_reachable, then remediate.plan, then shows the proposed PR in the editor. Nothing is applied without the developer saying yes. This is the pattern that replaces "open a ticket for a security engineer to look at" for the high-volume, low-complexity cases.
Pattern two: on-call incident response. A malware alert fires from Eagle. The on-call pastes the finding into their assistant and asks "blast radius?". The assistant calls classify.artifact for confirmation, reach.paths for the call-site list, and scan.repo --filter pkg:<name> for every repo that depends on the artifact. The output is a ranked list of services to notify. This beats a git-grep-and-guess flow by a lot, mostly because reachability is real data.
Pattern three: audit-evidence lookup. An auditor asks "what evidence do you have for NIST SI-2 during Q4?" Someone on the security team asks the assistant. It calls comply.evidence with the control and the date range, gets back structured evidence items, and composes a summary. The canonical artifact is still the Lino export, but the assistant-driven path is how ad-hoc questions get answered without a context switch.
# Example of what a client agent actually calls, roughly
resp = mcp.call("remediate.plan", {
"workspace": "acme-prod",
"finding_id": "fnd_01J9...",
"policy": { "allow_major_bump": False }
})
plan = resp["plan"] # griffin.plan/v3
for step in plan["steps"]:
print(step["id"], step["kind"], step["requires_approval"])
How Safeguard.sh Helps
The MCP Server is the programmatic surface that makes every other Safeguard capability available to AI assistants without bespoke integrations per client. Claude Desktop, claude.ai, Claude Code, ChatGPT, Cursor, Gemini, and Grok all call the same tools and get the same typed outputs; the tools are backed by Griffin 3.0, Eagle 3.0, Lino 2.0, the Gold Registry, and the reachability engine. Self-hosted and hosted deployments are both supported, the hosted endpoint is available in US, EU, and Gov regions with FedRAMP HIGH, IL7, and SOC 2 Type II coverage, and every call produces Lino evidence so AI-assisted actions are as auditable as human ones. For teams that want developer-laptop agentic use cases, the same tool surface is available via the Local Runner and the desktop application, which is how we think most teams should start.