Skip to main content
Glama
Lex6won
by Lex6won

scan_vendor_bundles

Scans vendored frontend bundles (static/*.min.js) for known component vulnerabilities, covering projects without package.json or node_modules.

Instructions

벤더링된 프런트엔드 라이브러리(static/*.min.js)의 컴포넌트 취약점을 검사합니다.

scan_path 결과에 vendor_bundles 가 비어 있지 않으면 반드시 이 도구로 이어서 검사하세요. 이 파일들은 소스 룰 검사에서는 제외되지만(미니파이드라 오탐만 나옴) 그 자체가 프로젝트가 실행하는 남의 코드이고 알려진 취약점이 붙습니다. package.json 도 node_modules 도 없는 프로젝트에서는 이것이 유일한 컴포넌트 발견 경로입니다(실측: xlsx 0.18.5 → CVE-2023-30533 등).

버전을 확정하지 못한 번들은 조회하지 않고 '판정 불가'로 남깁니다 — 추측한 버전으로 취약점을 단정하지 않기 위해서입니다. 판정 불가는 '안전'이 아닙니다.

결과를 scan_path 결과 JSON 의 dependency_audit 에 넣어 render_report 를 호출하세요. 이미 scan_dependencies 결과가 있다면 {"audits": [<의존성 결과>, <이 결과>]} 형태로 합쳐 넣습니다.

Input Schema

NameRequiredDescriptionDefault
callerNo호출 주체 자율 신고 (예: 'harness:auto'). 감사 구분용
env_gradeNo실행환경 등급 — 신규 버전 쿨다운 기준일만 정합니다(취약점·악성 판정에는 영향 없음): E0(개인PC 일회성, 3일) | E1(개인PC 반복도구, 7일, 기본) | E2(내부서버 공용, 14일). **사용자가 배포 환경을 명시하지 않으면 비워 두세요** — 도구가 자동 판별하지 않으며, 넘긴 값이 보고서에 '검사 실행 시 지정'으로 그대로 기록됩니다.
vendor_bundlesYesscan_path 결과 JSON 의 `vendor_bundles` 값을 **그대로** 전달 (직접 조립하지 말 것). 각 항목: {path, name, version, evidence, ecosystem}

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.4

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses a fail-closed policy (bundles whose version can't be pinned are not queried and left as 'undecidable', and 'undecidable' ≠ 'safe') and explains why guessing is avoided. It does not discuss network calls, caching, or rate limits, which keeps it short of a 5.

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?

Front-loaded with the purpose, then the when-to-use condition, then caveats and workflow. Every sentence carries content, though the multi-paragraph block is longer than strictly needed for a 3-parameter tool.

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?

An output schema exists, so return-format explanation is unnecessary. The description supplies everything else an agent needs: the trigger condition, the pass-through input contract, the fail-closed semantics, and the downstream render_report integration.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description's only parameter-adjacent guidance (pass vendor_bundles verbatim from scan_path, don't hand-assemble) is already stated in the schema's own property description, so the description adds no meaning beyond structured fields.

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?

States a specific verb+resource+scope: scanning component vulnerabilities in vendored frontend libraries (`static/*.min.js`). It explicitly contrasts with source-rule scanning (minified files are excluded there) and with package-manager auditing, letting an agent separate it from scan_dependencies and scan_path without opening schemas.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('if scan_path's vendor_bundles is non-empty, you MUST scan next'), an exclusion rationale (source rules produce only false positives on minified code), and the fallback case (no package.json / node_modules → this is the only component-discovery path). It also prescribes the downstream workflow: merge into dependency_audit with scan_dependencies results and call render_report.

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