> For clean Markdown of this page, append .md to its URL. For the complete documentation index, see https://www.superagent.sh/llms.txt.


Connect to Superagent's hosted MCP and share security context with your agents and scans.

# With Superagent

Use Security Graph through Superagent's hosted MCP endpoint at `https://www.superagent.sh/mcp`. Superagent manages the graph service, database, and catalog updates. Your setup is an organization API key and an MCP client connection.

Findings and reports remain the same records you review in the dashboard. If your agent already connects to Superagent MCP, use that existing connection for graph tools too.

## Connect an external agent

Create an organization API key in **Settings → API Keys** and configure your MCP client:

```json
{
  "mcpServers": {
    "superagent": {
      "url": "https://www.superagent.sh/mcp",
      "headers": {
        "Authorization": "Bearer ${env:SUPERAGENT_API_KEY}"
      }
    }
  }
}
```

Use your client's supported secret mechanism; environment interpolation varies by client. The key determines the organization automatically. An organization key grants organization-wide access, so use a dedicated key you can revoke independently.

Reconnect and discover tools such as `list_assets`, `get_context`, `get_classification_options`, and `set_finding_classification`. See the [MCP setup guide](https://www.superagent.sh/docs/mcp) for client-specific instructions.

## How Superagent scanners use it

Superagent's repository, application, agent, package, and PR scans receive a scoped `security-graph` MCP connection automatically. Superagent manages that connection, and the run determines its organization and asset access.

Before publishing a finding, each publishing agent must successfully search history through `search_context`. Agents can read matching records through `get_context`, including prior evidence, finding comments, triage decisions, and PR reviewer feedback. Another peer's search or a startup snapshot does not satisfy the publishing agent's history-read requirement.

Agents retrieve classification choices and include `catalog_version`, `type_ids`, `compliance_ids`, and `rationale` in their finding or PR result. Their guarded publication tools save the canonical finding and selected classification through Security Graph MCP in one transaction. No separate import or second graph submission is needed.

The history helps an agent reconsider issues already fixed, dismissed, or accepted as risk. Current evidence still determines whether a candidate should be reported.

## Use your own agent for assessments

An external MCP agent can use the same memory without starting a Superagent scan:

1. Discover an asset with `list_assets`, then inspect its graph with `get_context`. Use `list_findings` with search and asset filters to find relevant history.
2. Start an assessment record with `create_report`. Register an authorized external target with `create_asset` first if needed.
3. Investigate and call `submit_finding` with the structured evidence required by its schema.
4. Search `get_classification_options`, read current versions, and call `set_finding_classification` with both selected lists and the returned catalog version.
5. Complete your assessment execution with `finish_report`.

`create_report` records work performed by your agent and model. The separate `create_repository_report`, `create_web_app_report`, `create_agent_report`, and `create_package_report` tools launch billable Superagent assessments.

Finding submissions include Impact, Details, Policy Verification, Code References, PoC, and Remediation. Black-box assessments can explain unavailable source references or policy documents using the schema's required reason fields. Do not fabricate source or patch evidence. New submissions are attributed claims awaiting review.

## Comments and review decisions

Finding comments added through the dashboard, API, or MCP share the same discussion. MCP exposes `create_finding_comment`, `list_finding_comments`, `update_finding_comment`, and `delete_finding_comment`. Comments are attributed graph nodes linked to their finding, and their contents can be retrieved as later assessment context.

Use `update_finding_triage` for manual status changes, including PR findings:

| Status | Resolution |
| --- | --- |
| `new` or `in_review` | No resolution; reopening clears the previous resolution |
| `resolved` | `fixed`, `accepted_risk`, `false_positive`, or `wont_fix` |

Dashboard, API, and MCP transitions record who changed the state and retain before/after history. Adding a comment does not itself resolve or classify the finding. Completing a report review does not resolve its individual findings. See [Findings API](https://www.superagent.sh/docs/api/findings) for lifecycle details.

## Verify the connection

Ask your agent to find an existing finding, retrieve its comments and graph connections, and read its saved classification. After a test scan, verify that the new finding has the expected vulnerability-type and compliance connections. Confirm that a subsequent assessment can retrieve the earlier review context.

The dashboard's Security graph displays the records across your connected sources. Use search to find an asset or finding and select a node to inspect its connections.

## Next steps

- [How Security Graph works](https://www.superagent.sh/docs/security-graph)
- [Run it with your own database](https://www.superagent.sh/docs/security-graph/bring-your-own-database)
- [MCP tool reference](https://www.superagent.sh/docs/mcp#security-graph-tools)

---
Source: https://www.superagent.sh/docs/security-graph/superagent
Index: https://www.superagent.sh/llms.txt