Skip to main content
Glama
Sign In
Lex6won

vibecode-checker

by Lex6won
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

scan_dependencies

Parses dependency manifests and lockfiles to audit packages for existence, vulnerabilities, malware, and release cooldown, covering transitive dependencies.

Instructions

의존성 매니페스트를 파싱해 각 패키지의 실재·취약점·악성·쿨다운을 일괄 검사합니다.

scan_path 결과에서 requirements.txt·package.json 이 '검사 제외'로 표시되면 이 도구로 이어서 검사하세요.

네트워크: 온라인이면 공식 저장소와 OSV.dev에 패키지명·버전만 전송합니다 (소스 코드 미전송). GVSKB_MODE=offline(망분리)이면 외부 호출 없이 로컬 인텔 캐시로 대체하며, 실재·발행일은 '미확인'으로 표시됩니다.

락파일을 넣으면 전이 의존성까지 검사합니다. 실무 취약점은 대부분 매니페스트에 적히지 않은 전이 의존성에 있으므로, 락파일이 있으면 그쪽을 넣는 편이 정확합니다 (버전도 범위가 아니라 고정값이라 판정이 확실해집니다).

결과를 scan_path 결과 JSON의 dependency_audit 필드에 넣어 render_report를 호출하면 사람용 보고서에 '의존성 취약점' 섹션이 함께 렌더됩니다.

truncated_count > 0 이면 limit 로 잘려 검사되지 않은 패키지가 있다는 뜻입니다 — '이상 없음'이 아니므로 limit 를 올려 재검사하세요.

Input Schema

NameRequiredDescriptionDefault
limitNo검사할 최대 패키지 수. 미지정 시 형식에 맞춰 자동(매니페스트 20 · 락파일 500). 초과분은 truncated_count 로 표시
callerNo호출 주체 자율 신고 (예: 'harness:auto'). 감사 구분용
ecosystemNopypi | npm. 락파일이면 형식이 생태계를 확정하므로 이 값은 무시됩니다pypi
env_gradeNo실행환경 등급 — 신규 버전 쿨다운 기준일만 정합니다(취약점·악성 판정에는 영향 없음): E0(개인PC 일회성, 3일) | E1(개인PC 반복도구, 7일, 기본) | E2(내부서버 공용, 14일). **사용자가 배포 환경을 명시하지 않으면 비워 두세요** — 도구가 자동 판별하지 않으며, 넘긴 값이 보고서에 '검사 실행 시 지정'으로 그대로 기록됩니다.
manifest_textYes의존성 매니페스트 또는 **락파일**의 원문 텍스트. 매니페스트: requirements.txt·package.json / 락파일: package-lock.json·uv.lock·poetry.lock·pnpm-lock.yaml·yarn.lock

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.5.4
    • addedInput schema / properties / caller
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "호출 주체 자율 신고 (예: 'harness:auto'). 감사 구분용"
+}
    • addedInput schema / properties / ecosystem / description
      Added value: +"pypi | npm. 락파일이면 형식이 생태계를 확정하므로 이 값은 무시됩니다"
    • addedInput schema / properties / env_grade
      Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "E0",
+        "E1",
+        "E2"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "실행환경 등급 — 신규 버전 쿨다운 기준일만 정합니다(취약점·악성 판정에는 영향 없음): E0(개인PC 일회성, 3일) | E1(개인PC 반복도구, 7일, 기본) | E2(내부서버 공용, 14일). **사용자가 배포 환경을 명시하지 않으면 비워 두세요** — 도구가 자동 판별하지 않으며, 넘긴 값이 보고서에 '검사 실행 시 지정'으로 그대로 기록됩니다."
+}
    • addedInput schema / properties / limit / anyOf
      Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / limit / default
      Previous value: -20New value: +null
    • addedInput schema / properties / limit / description
      Added value: +"검사할 최대 패키지 수. 미지정 시 형식에 맞춰 자동(매니페스트 20 · 락파일 500). 초과분은 truncated_count 로 표시"
    • removedInput schema / properties / limit / type
      Removed value: -"integer"
    • addedInput schema / properties / manifest_text / description
      Added value: +"의존성 매니페스트 또는 **락파일**의 원문 텍스트. 매니페스트: requirements.txt·package.json / 락파일: package-lock.json·uv.lock·poetry.lock·pnpm-lock.yaml·yarn.lock"
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses exactly what leaves the machine over the network (package name/version to official registry and OSV.dev, no source code), the offline (GVSKB_MODE=offline) fallback behavior and the resulting '미확인' status, that lockfiles widen coverage to transitive deps, and that truncated_count means packages were NOT scanned.

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 core purpose, then organized into clearly themed paragraphs (routing, network, lockfiles, report integration, truncation). Each paragraph carries actionable content, though the length is on the heavier side for a five-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?

Complete for a five-parameter tool with a full schema and an output schema. The description need not explain return values but still covers the two operational outputs that matter (dependency_audit field for render_report, and truncated_count as a warning signal).

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: lockfile input causes ecosystem to be ignored, env_grade affects only the cooldown reference date and is not auto-detected, and limit defaults auto-scale to format. The only gap is that it doesn't tie these back to the parameter names explicitly.

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 and resources ('의존성 매니페스트를 파싱해 각 패키지의 실재·취약점·악성·쿨다운을 일괄 검사'), and explicitly distinguishes itself from the sibling scan_path by naming the condition ('scan_path 결과에서 ... "검사 제외"로 표시되면 이 도구로 이어서 검사하세요'). An agent can select it without opening the schema.

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 routing rule from scan_path, a strong preference rule for lockfiles over manifests (with the reason: transitive deps), and a recovery action when truncated_count > 0 ('limit 를 올려 재검사하세요'). It also tells the agent to leave env_grade blank when the user hasn't specified a deployment environment.

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

Deploy Server

Other Tools