Skip to main content
Glama
shyshlakov

pci-dss-mcp

check_dependencies

Scan Go dependencies in go.mod for known vulnerabilities and map findings to PCI DSS 6.3.3 compliance requirements.

Instructions

Scan go.mod dependencies for known vulnerabilities (PCI DSS 6.3.3). Bulk-downloads the public OSV Go vulnerability snapshot and intersects locally against go.mod, matching the govulncheck privacy model. No module names are sent to OSV.dev. Cache TTL: 24h fresh, 24h-7d revalidate via ETag, >7d force-refresh. Run update_vulnerability_db first to bootstrap the cache for air-gapped environments. Default: returns response_shape "summary" with by_severity counts, a capped by_rule histogram (top 10 + more_rules), and top 1 per severity findings - plus a pagination.next_cursor for drill-down. Prefer this for mixed queries; min_severity / rule_filter drop to response_shape "flat" but still carry summary.by_severity + summary.by_rule for full-scan context. Follow the cursor for the full paginated list. Use min_severity / rule_filter / positive limit for a filtered flat response. Maps findings to PCI DSS 6.3.3.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesrequired,Path to the project directory containing go.mod to scan for vulnerable dependencies
modeNoScan mode: only 'auto' (default) is supported after v0.6.3. Empty value is treated as 'auto'.
cursorNoOpaque cursor token from a prior check_dependencies response. When set resumes pagination from the stored session cache (10-minute TTL). Leave empty for a fresh scan.
limitNoMaximum number of findings to return per call. Default 0 (summary-first response with next_cursor). To fetch more findings than fit in one response, follow next_cursor; do NOT raise this value to fetch all at once (server caps at the per-tool page size and rejects with LIMIT_EXCEEDS_PAGE_SIZE).
min_severityNoFilter by minimum severity (CRITICAL/HIGH/MEDIUM/LOW/INFO). Setting this forces the flat response shape.
rule_filterNoFilter by rule ID, comma list or /regex/. Setting this forces the flat response shape.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given no annotations, the description covers key behaviors: bulk-downloads OSV snapshot, no module names sent (privacy), Cache TTL details, response shape defaults, and pagination. It lacks mention of auth requirements or rate limits but is otherwise thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded with the purpose. It covers caching, privacy, shapes, and parameters efficiently, though some sentences could be tightened. It earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description focuses on behavioral and usage context. It explains prerequisite, caching policy, response shape variants, pagination, and filtering. All aspects of a complex tool are addressed, making it self-sufficient for agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already has 100% parameter descriptions, but the description adds critical meaning: default mode, cursor usage for pagination, limit capping, and how min_severity/rule_filter change the response shape. This goes beyond schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool scans go.mod for vulnerabilities (PCI DSS 6.3.3). It specifies the resource ('go.mod dependencies') and action ('scan for vulnerabilities'), distinguishing it from sibling tools like update_vulnerability_db or check_tls_config.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage steps: run update_vulnerability_db first for air-gapped environments, use cursor for pagination, and apply min_severity/rule_filter for filtered responses. However, it does not explicitly contrast with other sibling tools beyond the prerequisite note.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shyshlakov/pci-dss-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server