Skip to main content
Glama
Sign In
Lex6won

vibecode-checker

by Lex6won
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

check_package

Verify a single package's existence, known vulnerabilities, malicious status, and release cooldown before running pip or npm install, catching typosquatted or AI-hallucinated names.

Instructions

단일 패키지의 실재·취약점·악성·발행경과일(쿨다운)을 설치 전에 확인합니다.

AI가 제안한 패키지를 pip/npm install 하기 전, 또는 이름이 수상한(오타 스쿼팅 의심) 패키지를 확인할 때 사용하세요. 매니페스트 전체를 검사하려면 scan_dependencies 를 씁니다.

판정(verdict): not_found=저장소에 없음(AI가 지어낸 이름 의심, 차단 권고) | malicious=악성 | vulnerable=알려진 취약점 | cooldown_hold=발행 직후라 대기 권고 | checked_clean=이상 없음 | unknown/error=판정 불가('안전' 아님) | registry_rejected=기관 레지스트리가 차단 | registry_approved=기관 레지스트리가 승인.

registry_* 는 이 도구의 관측이 아니라 기관의 결정입니다. 다만 malicious 는 승인보다 위입니다 — 승인은 시점의 판단이고 위협 정보는 그 뒤에도 갱신됩니다. registry_approved 인데 checked=false 면 '승인은 받았으나 이번에 로컬 위협 정보와 대조하지는 못했다'는 뜻입니다('안전 확인'이 아님).

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

Input Schema

NameRequiredDescriptionDefault
nameYes패키지 이름 (예: requests, express). 버전 표기 없이 이름만
callerNo호출 주체 자율 신고 (예: 'harness:auto', 'registry:manual'). 감사 구분용
versionNo검사할 버전(권장). 미지정 시 전체 버전 이력 기준이라 판정이 보수적
ecosystemNo패키지 저장소: pypi(Python) | npm(Node.js)pypi
env_gradeNo실행환경 등급 — 신규 버전 쿨다운 기준일만 정합니다(취약점·악성 판정에는 영향 없음): E0(개인PC 일회성, 3일) | E1(개인PC 반복도구, 7일, 기본) | E2(내부서버 공용, 14일). **사용자가 배포 환경을 명시하지 않으면 비워 두세요** — 도구가 자동 판별하지 않으며, 넘긴 값이 보고서에 '검사 실행 시 지정'으로 그대로 기록됩니다. E3(대민·개인정보)는 바이브코딩 대상이 아니므로 받지 않음

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.5.4
    • addedInput schema / properties / caller
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "호출 주체 자율 신고 (예: 'harness:auto', 'registry:manual'). 감사 구분용"
+}
    • addedInput schema / properties / ecosystem / description
      Added value: +"패키지 저장소: pypi(Python) | npm(Node.js)"
    • 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일). **사용자가 배포 환경을 명시하지 않으면 비워 두세요** — 도구가 자동 판별하지 않으며, 넘긴 값이 보고서에 '검사 실행 시 지정'으로 그대로 기록됩니다. E3(대민·개인정보)는 바이브코딩 대상이 아니므로 받지 않음"
+}
    • addedInput schema / properties / name / description
      Added value: +"패키지 이름 (예: requests, express). 버전 표기 없이 이름만"
    • addedInput schema / properties / version
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "검사할 버전(권장). 미지정 시 전체 버전 이력 기준이라 판정이 보수적"
+}
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it enumerates every verdict value with meaning, warns that unknown/error is not 'safe', clarifies that registry_* reflect institutional decisions rather than this tool's observation (and that malicious outranks approval), explains registry_approved+checked=false as 'not verified safe', and discloses network behavior (name/version only, no code, to pypi.org/npmjs.org and OSV.dev) plus offline GVSKB_MODE fallback behavior.

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?

Purpose and usage lead the description, followed by a well-organized verdict glossary and a network/offline note. The verdict enumeration is long but load-bearing for a safety-critical tool; it is only mildly more verbose than necessary given output_schema already exists.

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?

For a safety-gating tool with five parameters, no annotations, and an output schema, the description covers the decision space an agent needs: verdict meanings and their relative severity, the non-equivalence of 'unknown' to safe, network/offline behavior, and the pre-install decision context. Nothing material is missing.

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 description coverage is 100%, so the schema already documents name, version, ecosystem, caller, and env_grade in detail — including the version-vs-full-history conservatism tradeoff and the E0/E1/E2 cooldown windows. The description adds little parameter-level detail beyond what the schema states, so the baseline 3 applies.

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 opening sentence states a specific action (verify a single package) plus the exact attributes checked — existence, vulnerabilities, maliciousness, publish cooldown — before install. It explicitly separates itself from the sibling scan_dependencies for whole-manifest inspection, so an agent can pick the right tool without opening either 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?

It names the triggering conditions directly ('before pip/npm install of an AI-suggested package', 'typosquatting-suspect names') and routes the full-manifest case to scan_dependencies. Both the when-to-use and the alternative are stated rather than inferred.

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