MCP server
Connect Claude or an IDE to your supply-chain data over MCP.
TraceGuard ships a Model Context Protocol server, so an AI assistant (Claude, an IDE) can read and act on your supply-chain data — bounded by the same scopes and row-level security as everything else. A token can never see or change anything its owner couldn't. The connection reads what you can read in the app: organization owners and admins see every project of the organization; members see the organization-wide projects and the projects they were added to.
Connect
The server speaks Streamable HTTP at https://mcp.traceguard.io. In the app
this lives under Integrations → MCP — pick your client below to get the
server URL and a ready-to-paste config (the same flow as the product):
https://mcp.traceguard.io- 1. In Claude: Settings → Connectors → Add custom connector.
- 2. Paste the Server URL above.
- 3. Sign in to TraceGuard and approve — pick read-only vs read & write and which orgs/projects.
Works on claude.ai and Claude Desktop.
On first connect you sign in to TraceGuard and choose scope — read-only vs read &
write, and which orgs/projects. See OAuth for the flow,
or expand Use an API token above for headless/CI setups (tgm_…).
First call
Run whoami first — it reports the token's identity, granted scopes, and any
org/project restrictions, so you know exactly what this connection can do. Scopes
cap your organization-level permissions and decide which write tools appear; which
projects you can read is decided per request by your role and each project's
visibility.
Tool catalog
Read tools are always listed, and they return only what you can read; write tools only appear when the token holds the corresponding write scope.
| Group | Tools |
|---|---|
| Navigation | whoami, list_organizations, list_projects |
| Inventory | list_sboms, get_sbom, list_components, list_dependencies |
| Vulnerabilities | list_vulnerabilities, get_vulnerability, get_advisory |
| Code findings | list_code_findings (SAST, IaC, CI/CD, secrets) |
| Findings & triage | list_findings, list_vex, list_exclusions |
| Licenses & compliance | license_exposure, compliance_posture, list_compliance_reports (organization owners and admins) |
| Dashboard & search | org_dashboard_stats, kev_epss, search |
| Fix campaigns (read) | list_campaigns, list_campaign_candidates, get_campaign_activity |
| Coverage | explain_coverage (per part of a BOM: identified? checked? what hid its findings; verdicts active, hidden, none_known, identifier_unknown, not_identified, not_scanned, each with a hint) |
| Write (scope-gated) | create_vex, propose_finding_assessment, trigger_scan, upload_sbom (upload a BOM as a new version, up to 2 MB inline; parsing and scanning follow, poll get_sbom) |
Campaign control (autopilot:manage, org owner/admin) | create_or_update_campaign, set_campaign_state, decide_campaign_candidate, enqueue_campaign_fix, add_monitored_source (TraceGuard staff only) |
A vulnerability's severity is the advisory source's own label (GitHub's follows
CVSS v4 when the advisory has a v4 score), while cvss_score is the CVSS v3.x base
score when one exists, so the two can disagree; get_vulnerability names the source
in severity_basis. get_advisory returns the published advisory text, which a daily
job captures and which can lag behind the findings: until it is captured,
advisory_prose is not_captured and intel still carries the CVE, aliases, CWE,
severity and KEV/EPSS known for the id. Compliance reports (list_compliance_reports)
cover the whole organization and are readable by organization owners and admins.
List tools that page take either limit/offset or page/page_size (each
parameter's description gives the default and maximum), and their responses
include a pagination object. list_organizations, list_exclusions and
list_campaigns do not page: they return every row in one response, and all but list_organizations add total and truncated
(true if the server's 1,000-row cap cut the list short). A failed call comes
back as an MCP error result.
Record triage decisions with create_vex: a VEX statement that is not affected, affected
(with a response such as a planned fix or an accepted risk) or fixed takes a finding out of
the review queue, survives rescans and appears in VEX exports. An "under investigation"
statement is recorded and exported too, but keeps the finding in the queue until it is
decided.
Immutable exclusions (list_exclusions; Triage > Not applicable in the app) are the other
way a finding leaves the queue. The older record_finding_decision and
list_finding_decisions tools were removed on 2026-10-18: those notes were never read by
the queues or exports, and the finding-decisions API now answers writes with
410 finding_decisions_retired.
Getting oriented
Data is hierarchical: organizations contain projects. Most tools take an
organization_id (from list_organizations); many also accept a project_id
(from list_projects). Use the list_*, search, and dashboard tools to find
ids before calling a write tool — and confirm specifics with the user first.
Always confirm before invoking a write tool: they change your data, and
enqueue_campaign_fix can open a draft pull request.