agent-bom
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scanA | Run a full AI supply chain security scan and return an AI-BOM. Point it at a target with one of:
• project_path — a local project / repo directory ("scan this repo";
must be inside home or AGENT_BOM_MCP_WORKSPACE_ROOTS)
• repo_url — a public git repo URL (cloned + scanned, no checkout)
• config_path — a local MCP-config directory
• image — a Docker image
• sbom_path — an existing CycloneDX/SPDX SBOM
• package — a single package or MCP launch command (pair it with
It extracts package dependencies, looks up CVEs (online via OSV.dev and advisory sources unless offline mode is requested or configured), assesses config security (credential exposure, tool access), computes blast radius, and returns structured results. Scanning is fully static and read-only — repository and image contents are parsed, never executed. Returns: JSON. By default a bounded summary: counts (packages, agents, findings by severity/category), top findings, affected paths, and a result_id. Page any full-fidelity section with scan(result_id=..., section='findings', offset=0, limit=25). An incomplete scan (e.g. vulnerability source unavailable) is returned as an error result whose body is still JSON. |
| checkA | Check a specific package for known CVEs before installing. |
| intel_lookupA | Look up one advisory from the local threat-intel database. |
| policy_checkA | Evaluate a security policy against current scan results. |
| generate_sbomA | Generate a Software Bill of Materials (SBOM) for your AI agent setup. |
| complianceA | Return compliance posture with its source: the tenant's persisted evidence, or a labelled local scan. |
| remediateA | Generate a remediation plan for vulnerabilities in your AI agent setup. |
| exposure_pathsA | Return the attack-path queue in the dashboard's order, with why each path ranks where it does. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| quick-audit | Run a complete security audit of your AI agent setup |
| pre-install-check | Check an MCP server package for vulnerabilities before installing |
| remediation-plan | Draft a human-reviewed remediation plan without modifying files |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| profiles_resource | Task profiles and startup commands; no tool schemas or credentials |
| policy_template_resource | Get a default security policy template for agent-bom. Returns a ready-to-use policy with common rules: block critical CVEs, flag CISA KEV entries, warn on unverified servers, and limit credential exposure. |
| tool_metrics_resource | Return bounded MCP tool execution metrics for observability. |
| framework_controls_resource | Summarize framework coverage and the evidence surfaces behind each claim. |
TDQS
Scored across 8 tools
Most tools target distinct operations: scan (full audit), check (single package CVE), generate_sbom (SBOM export), policy_check, remediate, compliance, intel_lookup, exposure_paths. However, scan and generate_sbom both 'discover agents and extract dependencies', and policy_check/remediate internally run scans, creating mild overlap in scope. Descriptions do help distinguish them, keeping ambiguity low.
Mix of verb_noun (generate_sbom, intel_lookup, policy_check, exposure_paths) and bare nouns/verbs (scan, check, compliance, remediate). Consistent snake_case style throughout keeps it readable, but the verb-vs-noun convention is not uniform.
Eight tools is well within the ideal 3-15 range for a security scanning server. Each tool covers a distinct stage of the security workflow (scan, check, SBOM, policy, remediation, compliance, intel, attack paths), so each earns its place.
The surface covers the full security lifecycle: scanning, SBOM generation, CVE lookup, policy gating, remediation, compliance, and attack-path analysis. Minor gaps exist—no tools for managing/saving policies, comparing baseline scans, or suppressing/waiving findings—but core workflows are covered.