Repo Run Check

Check a cloned repo folder before installing it

check_local_repo

Read-onlyIdempotent

Statically scans a local repository's setup files and scripts for risky install hooks, URL dependencies, autorun tasks, and dangerous commands before you run install or setup steps.

Instructions

Statically scans a repository folder on the machine running this MCP server before you run npm install, pip install, make or its setup steps. It reads only these files if present (each up to 300 KB): README.md, package.json, install.sh, setup.sh, setup.py, requirements.txt, .vscode/tasks.json and Makefile. It looks for npm lifecycle scripts (preinstall/postinstall) that download or run code, typosquatted or URL dependencies, setup.py side effects, VS Code tasks that autorun on folder open, and dangerous commands in the README and scripts. Read-only: it never executes anything, never writes files and sends nothing over the network. Other source files are not inspected, so this is not a full malware scan. Returns verdict: no_red_flags (nothing matched; not proof of safety), review_before_running (at least one warning: read the flagged lines first) or dangerous (download-and-execute, encoded payloads, known malware hosts and similar: do not run), plus advice, files_checked, findings (level, code, message, file, line, evidence) and install_commands found in README code blocks. Use check_repo instead when the repo is only on GitHub and not cloned yet.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "check_local_repo"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes	Path to the repo's root folder on this machine, absolute or relative to the server's working directory. In Docker, the folder must be mounted into the container.

Output Schema

Name	Required	Description	Default
`path`	Yes
`advice`	Yes
`verdict`	Yes
`findings`	Yes
`files_checked`	Yes
`install_commands`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.1.0Oct 31, 2026

addedInput schema / properties / path / description

Added value: +"Path to the repo's root folder on this machine, absolute or relative to the server's working directory. In Docker, the folder must be mounted into the container."

addedInput schema / properties / path / maxLength
```
Added value: +4096
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "advice": {
+      "type": "string"
+    },
+    "files_checked": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "findings": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "code": {
+            "description": "machine-readable rule id, e.g. pipe_to_shell",
+            "type": "string"
+          },
+          "evidence": {
+            "description": "the matching text, clipped",
+            "type": "string"
+          },
+          "file": {
+            "type": "string"
+          },
+          "level": {
+            "enum": [
+              "info",
+              "warn",
+              "danger"
+            ],
+            "type": "string"
+          },
+          "line": {
+            "type": "number"
+          },
+          "message": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "level",
+          "code",
+          "message"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "install_commands": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "path": {
+      "type": "string"
+    },
+    "verdict": {
+      "enum": [
+        "no_red_flags",
+        "review_before_running",
+        "dangerous"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "path",
+    "verdict",
+    "advice",
+    "files_checked",
+    "findings",
+    "install_commands"
+  ],
+  "type": "object"
+}

First observedv0.1.0Oct 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world; the description adds substantive context beyond them: the exact files read and the 300 KB per-file cap, the assurance that nothing is executed, written or sent over the network, and the honest limitation 'this is not a full malware scan'. It also explains what each verdict means and the consequence ('do not run').

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 action and the pre-install trigger, then scope, then safety guarantees, then return values. Dense and largely waste-free, though the enumerated file list and the return-value recap push it toward the long side; a slightly tighter list would cost nothing.

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?

Covers everything an agent needs to call this correctly: what it inspects, what it ignores, that it is non-executing and local-only, the limits of its verdicts, and how to read the three verdict levels. An output schema exists, yet the brief verdict explanation still helps the agent act on results rather than just parse them.

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% and the schema already documents the single 'path' parameter including the Docker mount caveat, so the baseline is 3. The description earns a point by clarifying that the folder must be on the machine hosting the server, which reinforces the locality constraint the agent must respect.

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 resource ('statically scans a repository folder on the machine running this MCP server') and immediately bounds the scope to a named file list. It also names the sibling it is not ('check_repo instead when the repo is only on GitHub'), so the agent can discriminate 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 an explicit trigger ('before you run npm install, pip install, make or its setup steps') and an explicit exclusion routing to the alternative sibling for non-cloned GitHub repos. When-to-use, when-not-to-use and the alternative are all present.

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

Deploy Server