vibecode-checker

Overview Schema Source Related Servers Discussions Admin

scan_path

Scan local files or folders against public-sector security standards, skipping build/vendor dirs and binaries, without sending code to external APIs; report Korean audit findings with safe fixes.

Instructions

파일 또는 폴더를 공공기관 보안 기준으로 점검(보안·검토·체크·검사)합니다.

사용자가 "이 폴더/프로젝트 보안 점검해줘", "이 파일 검토/체크해줘", "안전한지 검사해줘"처럼 로컬 경로를 가리키면 이 도구를 사용하세요. 메모리의 코드 조각이면 대신 scan_code 를 씁니다. "기존 코드베이스 감사" 흐름의 진입점입니다.

경로를 로컬에서 순회하며 빌드·vendor 디렉터리를 건너뛰고 바이너리는 무시하며, 소스 코드를 외부 API로 전혀 보내지 않습니다. 각 발견 사항에는 why_it_matters 와 safe_fix 가 포함됩니다. 검사 후 render_report 로 한국어 보고서를 만드세요.

Input Schema

Name	Required	Description	Default
`path`	Yes	검사할 로컬 파일 또는 폴더의 절대·상대 경로. 원격 URL 불가(먼저 clone)
`caller`	No	호출 주체 자율 신고 (예: 'harness:auto'). 감사 구분용
`profile`	No	정책 프로파일 ID. 값: public-default-strict(기본·엄격) \| civil-complaint-chatbot \| internal-db-query \| web-civil-service	public-default-strict
`scenario`	No	용도 힌트 — 해당 시나리오 룰을 우선 적용. 값: web-app \| data-pipeline \| llm-integration \| agent
`max_files`	No	최대 검사 파일 수 (기본 20,000). 초과분은 skipped_files에 사유와 함께 기록
`max_file_bytes`	No	파일 하나의 크기 상한(바이트, 기본 8,000,000). 넘는 실행 소스는 coverage.oversized_source_files 에 남고 게이트는 승인을 내리지 않는다

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.5.4Oct 15, 2026

addedInput schema / properties / caller

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "호출 주체 자율 신고 (예: 'harness:auto'). 감사 구분용"
+}

addedInput schema / properties / max_file_bytes

Added value: +{
+  "default": 8000000,
+  "description": "파일 하나의 크기 상한(바이트, 기본 8,000,000). 넘는 실행 소스는 coverage.oversized_source_files 에 남고 게이트는 승인을 내리지 않는다",
+  "type": "integer"
+}

changedInput schema / properties / max_files / default
```
Previous value: -500New value: +20000
```

addedInput schema / properties / max_files / description

Added value: +"최대 검사 파일 수 (기본 20,000). 초과분은 skipped_files에 사유와 함께 기록"

addedInput schema / properties / path / description

Added value: +"검사할 로컬 파일 또는 폴더의 절대·상대 경로. 원격 URL 불가(먼저 clone)"

addedInput schema / properties / profile / description

Added value: +"정책 프로파일 ID. 값: public-default-strict(기본·엄격) | civil-complaint-chatbot | internal-db-query | web-civil-service"

addedInput schema / properties / scenario / description

Added value: +"용도 힌트 — 해당 시나리오 룰을 우선 적용. 값: web-app | data-pipeline | llm-integration | agent"

First observedv0.1.0Jun 13, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full disclosure burden and does well: it states traversal is local, build/vendor directories are skipped, binaries ignored, and source is never sent to an external API — the key trust concern for this tool. It also previews that findings carry why_it_matters and safe_fix. What is missing is mask/coverage behavior on partial scans and any permission or gating caveats, so it stops 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?

Purpose and trigger conditions are front-loaded in the first paragraph, with behavior and follow-up steps after. The parenthetical synonym lists ('보안·검토·체크·검사') and repeated framing add slight redundancy for keyword-matching reasons, but no sentence is truly wasted.

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

Completeness4/5

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

For a tool with six parameters, a rich output schema, and no annotations, the description covers purpose, trigger, privacy behavior, finding shape, and the render_report follow-up — enough for correct invocation. It leaves profile/scenario selection semantics entirely to the schema, which is acceptable but is the one area an agent might still need guidance on.

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 every parameter (path, caller, profile, scenario, max_files, max_file_bytes) is already documented in structured form. The description adds no syntax or default guidance beyond the schema — baseline 3 applies when the schema does the heavy lifting.

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 (점검/검사) plus the resource (local file or folder path) and the security standard being applied. It explicitly distinguishes itself from scan_code for in-memory snippets and names render_report as the downstream step, so an agent can place it among 15 siblings without opening a 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 literal user phrasings that should trigger this tool ('이 폴더/프로젝트 보안 점검해줘', '이 파일 검토/체크해줘'), states the negative case (in-memory code → scan_code instead), and positions the tool as the entry point of the codebase-audit flow. Nothing is left to inference.

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

Deploy Server