Skip to main content
Glama
Sign In
Repo Run Check

Repo Run Check

by devx-agent
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Check a shell command before running it

check_command
Read-onlyIdempotent

Statically scans one shell, Bash, or PowerShell command or short script for malware-installer patterns and download-and-execute risks before it runs, returning a verdict and flagged findings.

Instructions

Statically scans one shell, bash or PowerShell command (or a short script) for malware-installer patterns before anyone runs it. Use it whenever an agent is about to run a command copied from a README, issue, gist, website, chat or AI answer, and for one-liners like curl | sh or iwr | iex. It flags download-and-execute (curl/wget piped to a shell, iwr/irm piped to iex) from unknown hosts, encoded or obfuscated PowerShell, Windows LOLBins (mshta, certutil, rundll32...), commands that disable antivirus or Defender, and known malware domains. Well-known installers (rustup, Foundry, Anza and similar) are reported as info only. Offline: nothing is sent anywhere and the command is never executed. 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 findings (level, code, message, line, evidence). For a whole cloned folder use check_local_repo. For a GitHub repo that is not cloned yet use check_repo.

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": {
      "cmd": "<cmd>"
    },
    "name": "check_command"
  }
}

Input Schema

NameRequiredDescriptionDefault
cmdYesThe exact command or script text you plan to run, unmodified (1-20000 characters). Multi-line input is fine; each line is checked.

Output Schema

NameRequiredDescriptionDefault
adviceYes
verdictYes
findingsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.0
    • addedInput schema / properties / cmd / description
      Added value: +"The exact command or script text you plan to run, unmodified (1-20000 characters). Multi-line input is fine; each line is checked."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "advice": {
+      "type": "string"
+    },
+    "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"
+    },
+    "verdict": {
+      "enum": [
+        "no_red_flags",
+        "review_before_running",
+        "dangerous"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "verdict",
+    "advice",
+    "findings"
+  ],
+  "type": "object"
+}
  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?

Annotations already declare readOnly/idempotent/non-destructive and closed-world, and the description confirms and extends this with "nothing is sent anywhere and the command is never executed." It also discloses the flagging taxonomy (download-and-execute, encoded PowerShell, LOLBins, AV-disabling, malware domains), that well-known installers downgrade to info only, and the meaning of the verdict values with the caveat that no_red_flags is not proof of safety.

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?

The core purpose and the when-to-use rule are front-loaded, and the sibling routing sits at the end, which is the right structure. It is dense but long, with a couple of near-redundant clauses (listing patterns twice across the detection list and the verdict definition), costing a little tightness.

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, yet the description still usefully summarizes the verdict and findings shape (level, code, message, line, evidence) so the agent knows what to act on. Combined with offline guarantees, detection scope, and sibling routing, nothing an agent needs to call this correctly is missing.

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 single parameter is already well documented (1-20000 chars, multi-line). The description still adds scope meaning by framing the input as one command or short script that is checked line by line, reinforcing that this is not a file/folder scan; that is mild value beyond the schema, so just above baseline.

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 description opens with a specific verb and resource ("statically scans one shell, bash or PowerShell command (or a short script)") and enumerates the exact threat classes it looks for. It also explicitly closes by distinguishing itself from both siblings, so an agent can route 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?

It states precisely when to call it ("whenever an agent is about to run a command copied from a README, issue, gist, website, chat or AI answer") and names both alternatives with their selecting conditions: check_local_repo for a cloned folder, check_repo for an un-cloned GitHub repo. Implicit exclusions are made explicit.

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