Skip to main content
Glama
Sign In
Cybersec Toolkit

Cybersec Toolkit

by 26zl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

run_script

Destructive

Execute Python or Bash scripts in a temporary file and return stdout/stderr, enabling quick custom security checks, automation, and proof-of-concept testing.

Instructions

Write and execute a Python or Bash script, returning its output.

Writes the code to a temporary file, executes it via python3/bash, and returns stdout/stderr. The temp file is deleted after execution. Requires CYBERSEC_MCP_ALLOW_SCRIPTS=1. This is an explicit full-code execution opt-in: scripts run outside the MCP policy layer and are not constrained by CYBERSEC_MCP_ALLOW_EXTERNAL. Their only OS isolation is the launch mode: the Kata VM by default, none in --local mode.

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": {
      "code": "<code>"
    },
    "name": "run_script"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYesThe script source code to execute.
venvNoOptional Python venv name from ~/.ctf-venvs/ (e.g. "pwntools"). Allows using a different Python with specific packages installed. Ignored for language="bash". If not set, uses the MCP server's Python.
timeoutNoMaximum execution time in seconds (default 120, max 300).
languageNo"python" (default) or "bash".python
working_dirNoWorking directory for the script (default: system temp dir).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A3.9/5.0
Behavior5/5

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

Substantially exceeds the annotations: it discloses the temp-file lifecycle (created then deleted), the interpreter invocation, and critically that scripts bypass the MCP policy layer and CYBERSEC_MCP_ALLOW_EXTERNAL, with OS isolation only via Kata VM unless --local. These are exactly the risk facts an agent needs for a destructive, open-world tool.

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 return value, then security caveats in descending priority. A little restatement between sentence one and two ('write and execute' / 'writes the code to a temporary file'), but no sentence is filler.

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?

Output schema exists, so return-value explanation is rightly omitted, and the security/isolation model is unusually well covered for a tool with no config parameters. Minor gaps remain around timeout behavior and output truncation, but nothing that would cause an incorrect invocation.

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 code, venv, timeout, language and working_dir thoroughly. The description only echoes the Python/Bash choice and adds no syntax, default, or interaction detail beyond the structured fields, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb pair (write and execute) plus the resource (Python or Bash script) and the result (its output), which is easy to distinguish from run_tool / run_pipeline. It stops short of naming a sibling or stating the boundary explicitly, so differentiation is inferable rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a concrete prerequisite (CYBERSEC_MCP_ALLOW_SCRIPTS=1) and frames this as an explicit opt-in, which tells the agent when the tool is even available. However, it never says when to prefer this over run_tool or run_pipeline for a given task, so routing guidance is implied at best.

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